Vous êtes sur la page 1sur 24

Objetivos del curso

Ingeniera del Software I

Comprender los elementos caractersticos de la


ingeniera del software

Conocer de forma detallada los mtodos y


herramientas de especificacin de requisitos

3 I.T.I.Gestin

Ser capaz de elaborar la especificacin completa de


un sistema utilizando las herramientas, mtodos y
procedimientos mostrados en el curso

Miguel A. Laguna

Ingeniera del Software I

Introduccin a la Ingeniera del Software

1. Introduccin

Producto y Proceso
Aspectos de Gestin

Elicitacin, anlisis y especificacin de


Requisitos

Ingeniera del Software I


3 I.T.I.Gestin

Modelado de actividades y casos de uso


Modelado esttico (diagramas de clases)
Modelado dinmico (diagramas de secuencia)

Miguel A. Laguna
3

Desarrollo del tema

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

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

FAQs: Preguntas frecuentes

sobre Ingeniera del Software

1.1. El software y la
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

Importancia 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.

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

Costes del Software

Crecimiento espectacular de los costes


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

11

Los costes que representa el Software son a


menudo mayores que el hardware

El mantenimiento resulta ms caro que 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

El software se deteriora

Costes de los cambios


60-100x

Tasa de
fallos

Incremento de fallos

cambio

1.5-6x
1x

curva real
curva ideal

Definicin

Desarrollo

Despus de
entregado

Tiempo
13

Qu es la Ingeniera del software?

Disciplina que se ocupa del desarrollo del


software.

14

Ingeniera 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.

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.

15

Objetivos de la
Ingeniera 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

Mejorar la calidad del software


Acortar los tiempos de desarrollo
Aumentar la productividad
Necesidad:

16

Incrementar la reutilizacin del software

17

del problema a resolver,


las restricciones del desarrollo y
los recursos disponibles.
18

Cul es la diferencia entre Ingeniera del


Software y las Ciencias de la Computacin?

Cul es la diferencia entre Ingeniera del


Software e Ingeniera de Sistemas?

Las Ciencias de la Computacin tienen


que ver con teoras y fundamentos

La Ingeniera de Sistemas tiene que ver


con todos los aspectos del desarrollo de
sistemas basados en computadoras:
hardware, software e Ingeniera de
procesos.

La Ingeniera del Software tiene que ver


con los aspectos prcticos del desarrollo
del software

Ingeniera del Software es una parte de


este proceso

19

20

Disciplinas integradas en la
Ingeniera del Software

SWEBOK

Software Engineering Body of Knowledge (SWEBOK)

Requisitos del software


Diseo del software
Construccin del software
Prueba del Software
Mantenimiento del software

Requisitos del
software
Proceso de
Ingeniera de
Requisitos
Obtencin de
requisitos
Anlisis de
requisitos

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

Especificacin
de requisitos
Validacin de
requisitos
Gestin de
requisitos
(a)

Gua
SWEBOK (I))
(I

Dis
Diseo
Diseo
e
delsoftware
odel
del
ssoftware
oftw
are

Cons
Construccin
Constructr
cciin
del
software
uc
n
deldel
ssoftware
oftwa
Reduccin
de la
re

Prueba del
software

Mantenimiento
del software

complejidad

Conceptos bsicos
y definiciones

Conceptos
bsicos

Ellementos clave en el
diseo del software

Anticipacin de la
diversidad

Niveles de
pruebas

Proceso de
mantenimiento

Estructura y arquitectura
del software

Estructuracin para
la validacin

Tcnicas de
prueba

Principales
problemas
del mantenimiento

Uso de estndares
externos

Mtricas
relacionadas con
las pruebas

Conceptos y principios
bsicos

Anlisis y evaluacin de
la calidad del diseo
Notaciones
de diseo

Tcnicas para
el mantenimiento

Gestin del proceso


de prueba

Estrategias y mtodos
de diseo
(b)

(c)

21

(d)

(e)

22

SWEBOK
Gua
Gua
Gua
SWEBOK
(II)
SWEBO
SWEBOK
(II)
SWEB
OKK ((IIII))

Gestin
de
Gestin
de la
la
Gesti
configuracin
de
nconfiguracin
de la
la
configuracico
nfiguracinn
Gestin del proceso de
gestin de la configuracin

Gestin
Gestin
G
Gestin
de
estin
de la
la IS
IS
de
la
S
de
dela
la IIIIS
de
la
S
S
Gestin de
la organizacin

Conceptos del
proceso de IS

Herramientas
yy t
H
Herramientas
Heerramirramien
en
as
yy
mtodos
de la IS
tasmtodos
mtodosmtodos
de
de la
la IS
IS
Herramientas
software

Identificacin de lla
configuracin del software

Gestin delll
proceso/proyecto

Infraestructura del
proceso

Mtodos
software

Control de la configuracin
del software

Medida de la
IS

Medida del
proceso

Actividades y tcnicas para


SQA y V&V

Registro del estado de la


configuracin del software

Definicin del
proceso

Mtricas aplicadas all SQA


y a la V&V

Auditora de la gestin
de la configuracin

Anlisis cualitativo
del proceso

Gestin de la distribucin
del software

Implementacin y
cambio del proceso

(a)

(b)

Proceso
de
P
rroceso
Proceso
de
P
oces
IS
de
oIS
de
IS
IS

(c)

(d)

Calidad
del
Calidad
del
Calid
software
deldel
ad
software
sof
tware
Conceptos sobre
calidad del software
Propsito y planificacin
del SQA y de la V&V

(e)

1.2. Sistemas de
Informacin

23

Sistema y subsistemas

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).

Subsistemas:

Los sistemas no son entidades independientes,


existen en un entorno:

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.

El entorno afecta al funcionamiento y rendimiento del


sistema.
El sistema puede estar diseado para hacer cambios en
el entorno.
26

25

Qu es un sistema de
informacin?

Sistema y subsistemas

OBJETIVOS

Fijacin de nuevos objetivos

Sistema de Informacin: Est encargado de

SISTEMA DE
GESTIN

Informacin de objetivos

Informacin de
funcionamiento

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

Decisin de comportamiento

Entrada

Salida
SISTEMA FSICO
27

Qu es un sistema de
informacin?

Qu es un sistema de
informacin?

Objetivos

SIST. DE
GESTION

Inf. del sist.


fsico

Decisin de
comportamiento

Informacin

SIST. FISICO

Una empresa tpica cuenta con un SI compuesto por


los siguientes subsistemas:

Decisin para
su propio
control

SIST. DE INFORMACION
Interaccin
con el
sistema
fsico
Entrada

28

Salida

29

Subsistema de Recursos Humanos: Se ocupa tanto de la


gestin del personal como de la nmina.
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

Qu es un sistema de
informacin automatizado?

Propiedades emergentes

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.

La compleja relacin entre los subsistemas de


un sistema significa que ste es ms complejo
que la suma de sus partes.
Las propiedades 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

La fiabilidad del sistema

Se puede calcular a partir de las propiedades de


los componentes individuales.

1.3. Mtodo y Proceso

Depende de la fiabilidad de los componentes y su


interrelacin.

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

Componentes de un mtodo

Qu es un mtodo?

Together

Resulta necesario establecer un enfoque sistemtico


y disciplinado para llevar a cabo un desarrollo
software
Definiciones:

Rose

HERRAMIENTAS

UML

TECNICAS
PROCESO

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.)

Proceso: Define el marco de trabajo y permite un desarrollo


racional de la IS

UP

Tcnicas: Indican cmo construir tcnicamente el software. Incluyen


tcnicas de modelado

Conjunto de procedimientos, tcnicas, herramientas y un


soporte documental que ayuda a los desarrolladores a
realizar nuevo software
(Mario Piattini et al.)

Herramientas: Proporcionan el soporte automtico o


semiautomtico para el proceso y para las tcnicas
35

36

Actividades complementarias
de gestin

Qu es un proceso software?

Un conjunto estructurado de actividades y resultados


asociados que conducen a la creacin de un producto
de software:

Organizar, planificar y programar los


proyectos de software:
Estimacin del coste del proyecto
Planificacin y calendarizacin del proyecto
Gestin de la configuracin del software
Calidad del 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.

38

37

Especificacin de requisitos
del software

Especificacin 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 del sistema.

Requirements
elicitation and
analysis

Feasibility
study

Feasibility
report

Requirements
validation
System
models

Fases de la Ingeniera de Requisitos:

Requirements
specification

User and system


requirements

Estudio de viabilidad
Elicitacin y anlisis de requisitos
Especificacin de requisitos: los del usuario y los del sistema
Validacin de requisitos

Requirements
document

39

40

Diseo e implementacin

Diseo e implementacin

Etapa en la que se convierte la especificacin


del sistema en un sistema ejecutable
Diseo del software

Design activities
Architectural
design

Abstract
specification

Interface
design

Component
design

Data
structure
design

Algorithm
design

System
architecture

Software
specification

Interface
specification

Component
specification

Data
structure
specification

Algorithm
specification

Implementacin

Describir la estructura del software, los datos, las


interfaces entre componentes,

Requirements
specification

Transformar la estructura anterior en un programa


ejecutable

Las actividades de estas etapas estn muy


relacionadas y pueden interpolarse.

Design products

41

42

Validacin del Software

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

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

43

Etapas en el proceso de
pruebas

Prueba de unidades

Prueba de mdulos

Prueba de subsistemas

Se prueban colecciones de componentes dependientes

System
specification

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.

System
design

System
integration
test plan

Acceptance
test plan

Prueba del sistema

Requirements
specification

Se comprueban los componentes individuales

Etapas en el proceso de
pruebas

Acceptance
test

Service

Detailed
design

Sub-system
integration
test plan

System
integration test

Module and
unit code
and tess

Sub-system
integration test

Prueba de aceptacin

Se prueba con datos reales para comprobar que el sistema


es aceptable por el cliente.
45

Mantenimiento del software

Mantenimiento del software

46

El software es intrnsecamente flexible y puede


cambiar.
De la misma forma que los requisitos cambian segn
cambian las circunstancias del 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

Define system
requirements

Assess existing
systems

Existing
systems

Propose system
changes

Modify
systems

New
system

48

Ayuda automatizada al proceso


(CASE)

Tipos de herramientas 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

Tool type
Planning tools

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

50

Reengineering tools

Tipos de herramientas CASE

Testing tools
Debugging tools
Program analysis tools

CASE
technology

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

Multi-method
workbenches

Programming

Single-method
workbenches

Testing

General-purpose
workbenches

Planning tools

Specification

Language-specific
workbenches

51

1.4.
Disciplinas de gestin de
proyectos

Design

Implementation

Verification
and
Validation

52

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


1.4.1

(competencias de un jefe de proyecto)


Planificacin del proyecto

Planificacin del proyecto

Tareas a realizar y plan de trabajo

Estimacin del coste del 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

Estimacin del coste del


software

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 de la evolucin
Es imposible planificar sin estimar o
del mismo

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

Medicin
Estimacin
El plan de proyecto
Herramientas grficas

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?

Mtricas de la productividad

Mtricas relacionadas con el tamao.

nmero de lneas del cdigo fuente


nmero de instrucciones del cdigo objeto
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

Calidad y productividad

Mtricas de Puntos de funcin


measurement parameter count

weighting factor
simple avg. complex

number of user inputs

X 3

number of user outputs

X 4

number of user inquiries

X 3

number of files

X 7

10

15

number of ext.interfaces

X 5

10

Las mtricas basadas en volumen/unidad de


tiempo (lneas/programador-mes) son
imperfectas

count-total

no tienen en cuenta factores como la fiabilidad, el


mantenimiento,

La productividad se puede aumentar


generalmente a costa de la calidad

complexity multiplier
function points

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

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

2. Organizacin del proyecto.

Organizacin del equipo, personas involucradas y sus tareas

3. Anlisis de riesgos.

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.
Se consulta a varios expertos y entre ellos acuerdan 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.

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

7. Mecanismos de supervisin e informe.

Cundo y qu tipo de informe debe producirse

Posibles riesgos con su probabilidad y estrategias de reduccin


de riesgos propuestas

11

Diagramas para la gestin de proyectos

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

Duracin (das)
8
15
15
10
10
5
20
25
15
15
7
10

11/7

18/7

25/7

1/8

8/8

15/8

Los diagramas de barras muestran la planificacin


sobre el calendario

Red de actividades

Dependencias

14/7/99

15 days

M1

T3

8 days

T1 (M1)

29/8

5/9

12/9

5 days

4/8/99

25/8/99

T6

M4

M6

M3

start

22/8

25/7/99

4/7/99

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

15 days
T9

T1

7 days

20 days

15 days

T11

T7

T2
25/7/99

10 days

M2
T4

10 days

11/8/99

T5

M7

5/9/99
M8

15 days
T10

18/7/99

10 days
T12

M5
25 days
T8

Finish
19/9/99

Actividades en el calendario
4/7

Las tareas no deben ser demasiado pequeas.

Los diagramas de redes de actividades muestran las


dependencias de las tareas y el camino crtico

Duracin de las tareas y dependencias


Tarea
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12

Las notaciones grficas ilustran la planificacin del


proyecto
Muestran la descomposicin del proyecto en tareas.

Asignacin de personal

19/9

4/7

Start

11/7

18/7

25/

1/8

8/8

15/8

22/8

29/8

5/9

12/9

19/9

T4

Fred

T1
T2

T4
T8

M1
T7
T3
M5
T8

T11
T12

Jane

T1
T3

M3
M2
T6
T5

T9
Anne

T2

M4

T6

T9
M7
T10

Jim

M6

T10

T7

T11
M8

Mary

T5

T12
Finish

12

Problemas en la planificacin
1.4.2
Otras actividades de gestin

Estimar la dificultad de los problemas, y por


lo tanto el coste de desarrollar una solucin,
es difcil
La productividad no es proporcional al
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

Gestin de riesgos
Garanta de calidad
Gestin de la configuracin

Gestin del riesgo

Tabla de riesgos

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

Riesgo

Posibles riesgos:

Probabilidad Impacto

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

Ejemplo:
Software

Comerciales (competencia, etc.)


Financieros (econmicos, etc.)
Tcnicos (base tecnolgica slida y probada?)
De desarrollo (equipo experimentado?)

empotrado

depende de
hardware no
disponible

60%

4(crtico)

Ajustar pruebas a la
disponiblilidad del
HW
Utilizar simulacin

Conceptos de calidad

Garanta de calidad
Coste de los fallos encontrados en distintas etapas
100

60.00-100.00

10.00

10

Gestin y
Mitigacin del
Riesgo

Cmo se aplica al software?


Control de calidad: inspecciones, revisiones,
pruebas
Aseguramiento de la calidad: anlisis, auditora e
informes

3.00
1.50
1

0.75

1.00

Estndares de calidad: ISO 90003

Req.

Diseo

Pruebas
En uso
Prueba
Prog.
del sistema

gua para la aplicacin de la ISO 9001:2000 para la


adquisicin, suministro, desarrollo, instalacin y
mantenimiento de SOFTWARE y servicios de soporte.

13

MODELO DE MADUREZ DE LA CAPACIDAD


Garanta de calidad

Caractersticas

Nivel

Proceso y
Estandares

Inicial

Revisiones
formales

Anlisis
&
Informes

Planificacin de las
pruebas
Mtricas

Resultados

- 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 establecen programas de formacin del
personal de desarrollo y mantenimiento.

Repetible

- 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.

Productividad y
calidad escasa.
Riesgo mximo

Productividad y
calidad baja.
Riesgo alto.

MODELO DE MADUREZ DE LA CAPACIDAD


Caractersticas

Nivel

Resultados

SITUACIN DE CMM EN ESPAA. 5/200 6

-Los procesos son definidos:


estandarizados, documentados e institucionalizados.

Definido

- Los procesos de ingeniera y gerencia son estables y se


integran en uno slo.
- Existe un entendimiento comn de los procesos,
funciones y responsabilidades.
- La organizacin mantiene un grupo dedicado a la

Productividad y
calidad media.
Riesgo medio.

definicin, mejora y difusin del proceso

Gestionado

- Los procesos son medibles o cuantificables


- La productividad y la calidad se miden y registran para
cada proyecto
de la organizacin.
- Se fijan metas cuantitativas de la calidad del software.
-Mediante el uso de mtricas de software, se crea una
base cuantitativa para la evaluacin y estimacin en

Productividad y

calidad alta.

Riesgo mnimo.

proyectos futuros.

- Los procesos se mejoran continuamente.

Optimizado

- 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.

Gestin de la configuracin del


software

Gestin de la configuracin del software

Cambios en
Requisitos de negocio
Cambios en
Requisitos tcnicos
Cambios en
Requisitos de usuario

otros

programas

documentacin

modelos de software
Plan

datos
Pruebas
cdigo

Hay cambios
en muchas
piezas

datos

14

Gestin de la configuracin del software


HERRAMIENTAS
TECNICAS
PROCESO

1.5. Aspectos profesionales


y ticos de la Ingeniera del
Software

identificacin
control de versiones
control de cambios
auditora
informes
construccin

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

Software Engineering Body of Knowledge (SWEBOK)


Estndares de la Ingeniera del Software
Software Engineering Education Project
Software Engineering Code of Ethics and Professional
Practice

En Espaa: Colegios profesionales

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

87

ACM/IEEE-CS: cdigo tico

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.

89

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.

90

15

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

1.6.1
1.6.2
1.6.3
1.6.4

Qu es UML?
Arquitectura
Elementos de Modelado
Mecanismos de extensin

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
El lenguaje de modelado tiene un valor
aadido si dicho lenguaje es estndar.
92

Qu es UML?

UML- Objetivos

Unified Modeling Language


UML no es un mtodo OO
UML propone una notacin y una semntica universal.
Inicialmente:

Un lenguaje para especificar, construir y documentar


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 no fuerza a utilizar un mtodo concreto (distintos tipos


de problemas conducen a diferentes mtodos de anlisis y
diseo)
93

Odell
Shlaer-Mellor
Ciclo de vida de los objetos

Jacobson

Meyer

UML

Pre- y
Post-condiciones

Harel

Gamma et. al.

State Charts

Frameworks, patrones

Embly
Singleton

Fusion

Wirfs-Brock

Responsabilidades

Descripciones de operaciones,
Numeracin de mensajes

95

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

Participantes en UML

Rumbaugh

Mantener una independencia (?) de los mtodos y de los


lenguajes de programacin
Establecer bases formales (?)
Imponer un estndar mundial

94

UML aglutina mltiples enfoques


Booch

Establecer un lenguaje visual de modelado, expresivo y sencillo


(?) en su uso

Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson)


Digital Equipment
Hewlett-Packard
i-Logix (David Harel)
IBM
ICON Computing (Desmond DSouza)
Intellicorp and James Martin & co. (James Odell)
MCI Systemhouse
Microsoft
ObjecTime
Oracle
Platinium Technology
Sterling Software
Taskon
Texas Instruments
Unisys

96

16

UML: Evolucin

UML 2.x (08/2005)

Documentos pblicos

UML 1.3

Abril 1999:

Publicacin de UML 1.0


Enero 1997

UML 1.1

Estandarizacin

UML 1.0
Unificacin

Junio 96 y Octubre 1996

UML 0.9 & 0.91


Colaboradores y
expertos
Mtodo Unificado 0.8

OOPSLA95

Booch93

OMT-2

Fragmentacin
Otros mtodos

Booch91

Aspectos Novedosos

(2003)

UML 1.4

septiembre de 2001

Publicacin de UML 1.1


Septiembre 1997

UML 1.5

OMT-1

Definicin semi-formal del Meta-Modelo


asociado
Incluye stereotypes como mecanismo de
extensibilidad (usos particulares)
Incluye un lenguaje para expresar
restricciones, OCL (Object Constraint
Language) desarrollado por IBM

OOSE
97

98

Modelado con UML

Perspectivas de UML

UML ya es el lenguaje de modelado predominante


Participacin de importantes empresas
Aceptacin como notacin estndar OMG
Evidencias:

Use
UseCase
Case
Diagrams
Diagramas
Diagrams de
Secuencia

Herramientas UML, libros, Congresos, cursos, camisetas,

Scenario
Scenario
Diagrams
Diagramas
Diagrams de
Colaboracin

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

Scenario
Scenario
Diagrams
Diagramas
Diagrams de
Estados

Use
UseCase
Case
Diagrams
Diagramas
Diagrams de
Casos de Uso

State
State
Diagrams
Diagramas
Diagrams de
Clases

Modelo

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

Component
Component
Diagrams
Diagramas
Diagrams de

Diagramas de
Actividad

Distribucin

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


100

99

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

Jerarqua de modelos

Arquitectura
Arquitectura de cuatro capas, definida en la
especificacin Meta Object Facility del OMG:
Meta-metamodelo: define el lenguaje para
especificar 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

104

103

Modelado de objetos

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

Los objetos se relacionan con las clases de las que


son creados por la relacin SerInstanciaDe
(IsInstanceOf)

105

106

Houston

Pop = 2M
Ar ea = 40 SM

Pop = 2M
Area = 40 SM
Is In

Metamodelado...

Metamodelado...

IsIn

USA

Pop = 250M
Area = 200 SM

Pop
T ype = R eal

Se basa en la idea de modelar los tipos de


entidades (clases y relaciones) con que forman los
modelos

UML

Area

Attribute
type

T ype = R eal
H as Attri bute

H as Attri bute

H as Attri bute

Class

City

N oOfIns tanc es

H as R el ati ons hi p

H as R el ati ons hi p

Relationship
Sour c eC ar di nali ty

Cuando se ve la clase como un objeto, la clase es


una instancia de otra clase (o meta-clase)

USA

IsIn.Country

Pop = 250M

Sour c eC ar di nali ty = 0

T ar g etC ar di nali ty

Houston

N oOfIns tanc es = 1

Ar ea = 200 SM

T ar g etC ar di nali ty = 1

Pop
Type = Real

Attribute

Area
Type = Real

type

HasAttribute

HasAttribute

Class

City

NoOfInstances

HasRelationship

107

HasAttribute

NoOfInstances = 1

HasRelationship

Relationship

IsIn.Country

SourceCardinality
TargetCardinality

SourceCardinality = 0
TargetCardinality = 1

108

18

...Metamodelado

Terminologa de metamodelado...

La idea fundamental en el metamodelado es que


las entidades del modelo (ej: clases) juegan dos
papeles:

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 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...

...Terminologa de metamodelado

UML se define en cuatro niveles (la gua semntica


de UML representa justamente el nivel metamodelo)

111

112

UML: Notacin
1.6.3
Elementos de modelado en UML

Bloques

Elementos

Elementos y Relaciones
Diagramas UML
Vistas

Estructurales
De comportamiento
De Agrupacin
De anotacin

Relaciones
Diagramas

Mecanismos

Mecanismos de Especificacin
Divisiones
Adornos
Mecanismos de extensibilidad

114

19

Paquetes en UML

Bloques y relaciones
Clase

Objeto

Atributos

Atributos

Mtodos

Mtodos

Estado

Caso de
Uso

Nodo

Interfaz

Actor

Pueden anidarse a su vez.

Su utilidad final es ganar claridad

Componente

Nota

Paquete

Son elementos auxiliares de organizacin y pueden contener


cualquier elemento de modelado.

Nombre
Dependencia
Asociacin

Nombre

Generalizacin

Nombre

116

115

Notas

Nombre

Realizacin

UML- Diagramas

Una nota es un comentario en el diagrama, que ir


unida a l o a uno de sus elementos..

Ejemplo de una

Clase

nota asociada a una clase

Atributos
Mtodos

117

Diagramas de estructura

118

Diagramas de comportamiento

119

120

20

UML- Diagramas

Elicitacin de requisitos de usuario

Diagrama de Clases

Diagrama de Componentes
Diagrama de Distribucin

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

Modelado de interaccin

Modelado de la estructura esttica/implementacin

Casos de Uso

Modelado de la estructura esttica/anlisis y diseo

UML- Casos de uso

Diagrama de secuencia
Diagrama de comunicacin

Precisa otras tcnicas complementarias para ser


utilizada en procesos de modelado OO

Modelado dinmico

Diagrama de Estados
Diagrama de Actividades

121

UML- Casos de uso

UML- Diagrama de Clases

caso de uso

incorporar
libros
include

extend
consultar
libro

actor

122

crear nuevo
cdigo

Bibliotecario

include

Proviene de los diagramas de entidad-relacin de Chen (70s)


Fueron extendidos con conceptos de AOO, como generalizacin
y agregacin (80s)
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

realizar
prstamo

Alumno

123

124

UML- Diagrama de Clases

UML- Diagrama de Secuencia

Persona
Autor

asociacin

1
generalizacin
Alumno

clase

solicita
0..*

0..*

1..*
Libro

navegabilidad

Prstamo

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

nota

clase asociacin

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

UML- Diagrama de Comunicacin

objeto 3

Es otro de los diagramas de interaccin que se


incluye en el UML

inicio de un mtodo
auto-delegacin

activacin
retorno
destruccin de un
objeto

No permite observar grficamente la cronologa de


los mensajes

Facilita la organizacin de los objetos en paquetes

Destaca la conexin esttica entre los objetos

127

128

UML- Diagrama de Comunicacin

UML- Diagrama de estados

1: maximo_alcanzado ( )
: Usuario

: bibliotecario

2: ejemplares disponibles ( )

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

: 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

131

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

132

22

UML- Diagrama de Actividad


Buscar
transporte

Se va en
su auto

Cambia de
marcha

1.6.4
Mecanismos generales de
extensin de UML

Toma un
taxi

Estereotipos.
Restricciones.
Valores etiquetados.

Mira por el
espejo

Entra a su
trabajo

133

Mecanismos de extensin:

Estereotipos

Mecanismos de UML

Tipos de mecanismos

Mecanismos de Especificacin

Divisiones (dicotomas)

Adornos

Completa el aspecto grfico

Un estereotipo es un nuevo tipo de elemento de


modelado.
Los estereotipos se representan encerrados en los
smbolos o mediante iconos

Ej: clase y objeto, operacin y mtodo.


Se pueden aadir detalles como la multiplicidad de una
relacin

Mecanismos de extensibilidad

Estereotipos
Valores etiquetados
Restricciones (OCL)
136

135

Mecanismos de extensin:

Mecanismos de extensin:

Restricciones:

Valores etiquetados:

Se pueden aadir propiedades a los elementos de


UML. Consisten en parejas de etiqueta + valor

Ventana

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

137

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)
138

23

Mecanismos de extensin:

Mecanismos de extensin:

Restricciones:

Restricciones: OCL

Miembro de

*
Persona

*
Persona

jefe

Comit

{Subconjunto}
1

trabajador

Preside
Empleado
*

Empleador
0..1

Empresa

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.

0..1

vuelo.piloto.horas_de_entrenamiento > horas.avin.horas_min


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

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

Caso de estudio: Punto de venta

Bibliografa general

140

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.

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

Referencia: libro de Larman

141

Las ventas se registran a travs


de un terminal punto-de-venta (TPDV)

142

Enfoque: Se pretende
independizar las capas del sistema:

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


cantidad.
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...

Capa de objetos
del dominio

Capa de servicios

Venta

Registro

Pago

Foco
principal

Persistencia

Actualizar automticamente el stock de cada producto


El cajero debe identificarse (nombre y contrasea) para utilizar un
terminal
143

144

24

Vous aimerez peut-être aussi