1

Ingeniera del Software I

3 I.T.I.Gestin
Miguel A. Laguna
Objetivos del curso
Comprender los elementos caractersticos de la
ingeniera del software
Conocer de forma detallada los mtodos y
herramientas de especificacin de requisitos
2
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
3
Elicitacin, anlisis y especificacin de
Requisitos
Modelado de actividades y casos de uso
Modelado esttico (diagramas de clases)
Modelado dinmico (diagramas de secuencia)
1. Introduccin
Ingeniera del Software I
3 I.T.I.Gestin
Miguel A. Laguna
Objetivos
Presentar la disciplina de ingeniera del
software y explicar su importancia
Preguntas ms frecuentes (FAQs) sobre
5
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
6
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)
2
FAQs: Preguntas frecuentes
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?
7
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)?
1.1. El software y la
Ingeniera del 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:
Qu es el Software?
9
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
Importancia del Software
10
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
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 ms caro que el
Costes del Software
12
a e e o esu a s a o que e
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
3
Costes de los cambios
60-100x
13
Definicin Desarrollo
1x
1.5-6x
Despus 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 Ingeniera del software?
15
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
Ingeniera del software
16
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.
Objetivos de la
Ingeniera del software
Mejorar la calidad del software
Acortar los tiempos de desarrollo
Aumentar la productividad
17
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
18
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.
4
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
19
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:
20
hardware, software e Ingeniera de
procesos.
Ingeniera del Software es una parte de
este proceso
Disciplinas integradas en la
Ingeniera del Software
Software Engineering Body of Knowledge (SWEBOK)
Requisitos del software
Diseo del software
Construccin del software
P b d l S ft
21
Prueba del Software
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
SWEBOK Gua
SWEBOK (I)
Gua
SWEBOK (I)
Requisitos del
software
Requisitos del
software
Proceso de
Ingeniera de
Requisitos
Diseo
del software
Diseo
del software
Conceptos y principios
bsicos
Diseo
del software
Diseo
del software
Conceptos y principios
bsicos
Construccin
del software
Construccin
del software
Reduccin de la
complejidad
Construccin
del software
Construccin
del software
Reduccin de la
complejidad
Prueba del
software
Prueba del
software
Conceptos bsicos
y definiciones
Mantenimiento
del software
Mantenimiento
del software
Conceptos
bsicos
22
(a) (a) (b) (b) (c) (c) (d) (d) (e) (e)
Obtencin de
requisitos
Anlisis de
requisitos
Especificacin
de requisitos
Validacin de
requisitos
Gestin de
requisitos
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
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
Anticipacin de la
diversidad
Estructuracin para
la validacin
Uso de estndares
externos
Anticipacin de la
diversidad
Estructuracin para
la validacin
Uso de estndares
externos
Niveles de
pruebas
Tcnicas de
prueba
Mtricas
relacionadas con
las pruebas
Gestin del proceso
de prueba
Proceso de
mantenimiento
Principales
problemas
del mantenimiento
Tcnicas para
el mantenimiento
SWEBOK
Gua
SWEBOK (II)
Gua
SWEBOK (II)
Gestin de la
configuracin
Gestin de la
configuracin
Gestin del proceso de
gestin de la configuracin
Id tifi i d l
Gestin
de la IS
Gestin
de la IS
Gestin de
la organizacin
G ti d l
Proceso de
IS
Proceso de
IS
Conceptos del
proceso de IS
Herramientas y
mtodos de la IS
Herramientas y
mtodos de la IS
Herramientas
software

Calidad del
software
Calidad del
software
Conceptos sobre
calidad del software
f
Gua
SWEBOK (II)
Gua
SWEBOK (II)
Gestin de la
configuracin
Gestin de la
configuracin
Gestin del proceso de
gestin de la configuracin
Id tifi i d l
Gestin de la
configuracin
Gestin de la
configuracin
Gestin del proceso de
gestin de la configuracin
Id tifi i d l
Gestin
de la IS
Gestin
de la IS
Gestin de
la organizacin
G ti d l
Gestin
de la IS
Gestin
de la IS
Gestin de
la organizacin
G ti d l
Proceso de
IS
Proceso de
IS
Conceptos del
proceso de IS
Proceso de
IS
Proceso de
IS
Conceptos del
proceso de IS
Herramientas y
mtodos de la IS
Herramientas y
mtodos de la IS
Herramientas
software

Herramientas y
mtodos de la IS
Herramientas y
mtodos
Herramientas
software

Calidad del
software
Calidad del
software
Conceptos sobre
calidad del software
f
Calidad del
software
Calidad del
software
Conceptos sobre
calidad del software
f
23
(a) (a) (b) (b) (c) (c) (d) (d) (e) (e)
Identificacin de la
configuracin del software
Control de la configuracin
del software
Registro del estado de la
configuracin del software
Auditorade la gestin
de la configuracin
Gestin de la distribucin
del software
Gestin del
proceso/proyecto
Medida de la
IS
Infraestructura del
proceso
Medida del
proceso
Definicin del
proceso
Anlisis cualitativo
del proceso
Implementacin y
cambio del proceso
Mtodos
software
Propsito y planificacin
del SQA y de la V&V
Actividades y tcnicas para
SQA y V&V
Mtricas aplicadas al SQA
y a la V&V
(a) (a) (b) (b) (c) (c) (d) (d) (e) (e)
Identificacin de la
configuracin del software
Control de la configuracin
del software
Registro del estado de la
configuracin del software
Auditorade la gestin
de la configuracin
Gestin de la distribucin
del software
Identificacin de la
configuracin del software
Control de la configuracin
del software
Registro del estado de la
configuracin del software
Auditorade la gestin
de la configuracin
Gestin de la distribucin
del software
Gestin del
proceso/proyecto
Medida de la
IS
Gestin del
proceso/proyecto
Medida de la
IS
Infraestructura del
proceso
Medida del
proceso
Definicin del
proceso
Anlisis cualitativo
del proceso
Implementacin y
cambio del proceso
Infraestructura del
proceso
Medida del
proceso
Definicin del
proceso
Anlisis cualitativo
del proceso
Implementacin y
cambio del proceso
Mtodos
software
Mtodos
software
Propsito y planificacin
del SQA y de la V&V
Actividades y tcnicas para
SQA y V&V
Mtricas aplicadas al SQA
y a la V&V
Propsito y planificacin
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
5
Qu es un sistema?
Un conjunto de elementos (hombres,
mquinas, mtodos, reglas) en interaccin,
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 diseado para hacer cambios en
el entorno.
Sistema y subsistemas
Subsistemas:
Sistema fsico: Transforma un flujo fsico de
entradas en un flujo fsico de salidas.
26
nivel operativo de la organizacin.
Sistema de gestin: controla el sistema fsico,
decidiendo el comportamiento del mismo en
funcin de los objetivos marcados.
Sistema y subsistemas
SISTEMA DE
GESTIN
OBJETIVOS
Informacin de objetivos
Fijacin de nuevos objetivos
27
GESTIN
SISTEMA FSICO
Decisin de comportamiento
Informacin de
funcionamiento
Entrada Salida
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
28
recibir decisiones sobre su propio control
interaccionar con el sistema fsico
Qu es un sistema de
informacin?
SIST. DE
GESTION
Decisin para
Objetivos
29
SIST. DE INFORMACION
SIST. FISICO
Entrada Salida
Informacin
Interaccin
con el
sistema
fsico
Decisin para
su propio
control
Inf. del sist.
fsico
Decisin de
comportamiento
Qu es un sistema de
informacin?
Una empresa tpica 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
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.
6
Qu es un sistema de
informacin automatizado?
Si todas las transformaciones significativas
son efectuadas por mquinas
31
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 i d d
32
Las propiedades emergentes son
consecuencia de las relaciones entre los
componentes.
Slo pueden asegurarse y observarse cundo
el sistema se considera como un todo.
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
33
La fiabilidad del sistema
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.
1.3. Mtodo y Proceso
Qu es un mtodo?
Resulta necesario establecer un enfoque sistemtico
y disciplinado para llevar a cabo un desarrollo
software
Definiciones:
35
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
(J ames 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.)
Componentes de un mtodo
PROCESO
TECNICAS
HERRAMIENTAS
UML
Together
Rose
36
PROCESO
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
7
Qu es un proceso software?
Un conjunto estructurado de actividades y resultados
asociados que conducen a la creacin de un producto
de software:
37
Especificacin de requisitos: Definir la funcio-
nalidad 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.
Actividades complementarias
de gestin
Organizar, planificar y programar los
proyectos de software:
Estimacin del coste del proyecto
38
p y
Planificacin y calendarizacin del proyecto
Gestin de la configuracin del software
Calidad del software
....
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
ifi i d l i t
39
especificacin del sistema.
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
Feasibility
report
40
validation report
System
models
User and system
requirements
Requirements
document
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 los datos las
41
Describir la estructura del software, los datos, las
interfaces entre componentes,
Implementacin
Transformar la estructura anterior en un programa
ejecutable
Las actividades de estas etapas estn muy
relacionadas y pueden interpolarse.
Diseo e implementacin
Architectural Abstract Interface Component
Data
Algorithm
Requirements
specification
Design activities
42
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
Design products
8
Tcnicas de diseo
Formas sistemticas de disear el
sistema
Generalmente se documenta con
43
Generalmente se documenta con
modelos grficos:
Diagramas de flujo de datos (DFDs)
Diagramas Entidad-Relacin
Diagramas de estructura
Modelos orientados a objetos
Validacin del Software
La verificacin y la validacin pretenden
demostrar que un sistema es conforme
con su especificacin y que resuelve los
44
requisitos del cliente
La prueba del sistema implica ejecutar
el sistema con los casos de prueba que
se obtuvieron en la especificacin.
Etapas en el proceso de
pruebas
Prueba de unidades
Se comprueban los componentes individuales
Prueba de mdulos
Se prueban colecciones de componentes dependientes
45
Se prueban colecciones de componentes dependientes
Prueba de subsistemas
Los mdulos se integran en subsistemas y se prueban. Sobre
todo se prueba el acoplamiento de las interfaces.
Prueba del sistema
Se prueban las interacciones entre los subsistemas y las
propiedades emergentes.
Prueba de aceptacin
Se prueba con datos reales para comprobar que el sistema
es aceptable por el cliente.
Etapas en el proceso de
pruebas
Requirements
specification
System
specification
System
design
Detailed
design
Module and Sub-system System
46
Module and
unit code
and tess
Sub-system
integration
test plan
System
integration
test plan
Acceptance
test plan
Service
Acceptance
test
System
integration test
Sub-system
integration test
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 el software
47
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.
Mantenimiento del software
Assess existing
systems
Define system
requirements
Propose system
changes
Modify
systems
48
systems requirements changes systems
New
system
Existing
systems
9
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.
49
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
Tipos de herramientas CASE
Tool type Examples
Planning tools PERT tools, estimation tools,
spreadsheets
Editing tools Text editors, diagrameditors, word
processors
Changemanagementtools Requirements traceability tools, change
control systems
50
Configurationmanagement tools Version management systems, system
building tools
Prototyping tools Very high-level languages,
user interfacegenerators
Method-supporttools Designeditors, datadictionaries, code
generators
Language-processing tools Compilers, interpreters
Programanalysis tools Cross referencegenerators, static
analysers, dynamic analysers
Testing tools Test datagenerators, filecomparators
Debuggingtools Interactivedebugging systems
Documentation tools Pagelayout programs, imageeditors
Re-engineering tools Cross-referencesystems, programre-
structuring systems
Tipos de herramientas CASE
Environments Workbenches Tools
CASE
technology
51
Single-method
workbenches
General-purpose
workbenches
Multi-method
workbenches
Language-specific
workbenches
Programming Testing
Analysis and
design
Integrated
environments
Process-centred
environments
File
comparators
Compilers Editors
Reengineering tools
Testing tools
Debugging tools
Program analysis tools
Language-processing
tools
Method support tools
Prototyping tools
Configuration
52
Configuration
management tools
Change management tools
Documentation tools
Editing tools
Planning tools
Specification Design Implementation Verification
and
Validation
1.4.
Disciplinas de gestin de
proyectos
Objetivos de la gestin de
proyectos
Organizar, planificar y programar los
proyectos de software
Disciplinas y tcnicas: Disciplinas y tcnicas:
Planificacin y estimacin de costes
Garanta de calidad
Gestin de la Configuracin
Gestin de personal

10
(competencias de un jefe de proyecto)
Planificacin del proyecto
Tareas a realizar y plan de trabajo
d l d l
Tareas de gestin de proyectos
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
1.4.1
Planificacin del proyecto
Medicin
Estimacin
El plan de proyecto
Herramientas grficas
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
del mismo
Es imposible planificar sin estimar o
estimar sin medir
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?
Se intenta determinar una medida de la
cantidad de software y de documentacin
asociada que produce un programador
individual
Medicin de la Productividad
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 relacionadas con el tamao.
nmero de lneas del cdigo fuente
nmero de instrucciones del cdigo objeto
Mtricas de la productividad
g 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.
11
Mtricas de Puntos de funcin
number of user inputs

number of user outputs
measurement parameter
3

4
count
weighting 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 mtricas basadas en volumen/unidad de
tiempo (lneas/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
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 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
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 l i ll d 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
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.
Posibles riesgos con su probabilidad y estrategias de reduccin
de 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. Divisin del trabajo.
Divisin del proyecto en actividades, marca hitos y 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
12
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 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. 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 Duracin (das) 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
M3
T6
4/7/99
8 days
14/7/99 15 days
4/8/99
15 days
25/8/99
7 days 20 days
5 days
25/7/99
15 days
T1
M1 T3
T9
M6 M4
T2
Finish
T10
M7
T5
T7
M2
T4
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 calendario
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1
T2
M1
T7
T3
M5
Start
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Finish
Asignacin de personal
4/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 planificacin
Estimar la dificultad de los problemas, y por
lo tanto el coste de desarrollar una solucin,
es difcil
L d i id d i l l 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
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 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
Escala 1..5
Riesgo Probabilidad Impacto
Gestin y
Mitigacin del
Riesgo
Escala 1..5
1=impacto
bajo
5=catstrofe
Ejemplo:
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
10
1
Req.
Diseo
Prog.
Pruebas
En uso
0.75
1.00
1.50
3.00
10.00
Prueba
del sistema
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.
14
Garanta de calidad
Revisiones
formales
Proceso y
Estandares
Planifica-
cin de las
pruebas
Mtricas
Anlisis
&
Informes
Nivel Caractersticas Resultados
Inicial
- 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.
S t bl d f i d l
Productividad y
calidad escasa.
Riesgo mximo
MODELO DE MADUREZ DE LA CAPACIDAD
- 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 baja.
Riesgo alto.
MODELO DE MADUREZ DE LA CAPACIDAD
Nivel Caractersticas Resultados
Definido
-Los procesos son definidos:
estandarizados, documentados e institucionalizados.
- 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
proyectos futuros.
Productividad y
calidad alta.
Riesgo mnimo.
Optimizado
- 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.
SITUACIN DE CMM EN ESPAA. 5/2006
Gestin de la configuracin del
software
Requisitos tcnicos
Cambios en
Requisitos de negocio
C bi
Cambios en
datos
otros
cdigo
Pruebas
Plan
modelos de software
Cambios en
Requisitos de usuario
Gestin de la configuracin del software
programas
documentacin
datos
Hay cambios
en muchas
piezas
15
Gestin de la configuracin del software
PROCESO
TECNICAS
HERRAMIENTAS
identificacin
control de versiones
control de cambios
auditora
informes
Existen herramientas que ayudan al control de
las versiones a medida que avanzan (SourceForge)
informes
construccin
1.5. Aspectos profesionales
y ticos de la Ingeniera del
Software
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)
E d d l I i d l S f
87
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
88
Los Ingenieros de Software deben
comportarse de modo honesto y tico si
quieren lograr respeto como profesionales
Es algo ms que cumplir la ley
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,
89
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.
J uicio: 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
90
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.
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 extensin
Por qu se necesita un
lenguaje de modelado?
Los sistemas complejos son difciles de
entender si no se cuenta con un modelo que
los describa
92
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.
Qu es UML?
Unified Modeling Language
UML no es un mtodo OO
UML propone una notacin y una semntica 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, 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)
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 (?)
94
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
UML aglutina mltiples enfoques
Rumbaugh
J acobson
Odell
Booch
Meyer
Pre y
95
UML
Embly
Gamma et. al.
Pre- y
Post-condiciones
Singleton
Frameworks, patrones
Harel
Wirfs-Brock
Fusion
Shlaer-Mellor
State Charts
Responsabilidades
Descripciones de operaciones,
Numeracin de mensajes
Ciclo de vida de los objetos
Participantes en UML
Rational Software (Grady Booch, J im Rumbaugh y Ivar J acobson)
Digital Equipment
Hewlett-Packard
i-Logix (David Harel)
IBM
( d )
96
ICON Computing (Desmond DSouza)
Intellicorp and J ames Martin & co. (J ames Odell)
MCI Systemhouse
Microsoft
ObjecTime
Oracle
Platinium Technology
Sterling Software
Taskon
Texas Instruments
Unisys
17
UML: Evolucin
UML 1.1
Publicacin de UML 1.1
Septiembre 1997
s

p

b
l
i
c
o
s
Estandarizacin
UML 1.3 Abril 1999:
UML 1.4
UML 2.x (08/2005)
septiembre de 2001
UML 1.5 (2003)
97
Otros mtodos Booch91 OMT-1 OOSE
Booch93 OMT-2
OOPSLA95 Mtodo Unificado 0.8
J unio 96 y Octubre 1996 UML 0.9 & 0.91
UML 1.0
Publicacin de UML 1.0
Enero 1997
Colaboradores y
expertos
D
o
c
u
m
e
n
t
o
s
Fragmentacin
Unificacin
Aspectos Novedosos
Definicin semi-formal del Meta-Modelo
asociado
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
Participacin de importantes empresas
Aceptacin como notacin estndar OMG
Evidencias:
99
Herramientas UML, libros, Congresos, cursos, camisetas,
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
Modelado con UML
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Casos de Uso
State
Diagrams
State
Diagrams
Diagramas de
Objetos
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Secuencia
State
Diagrams
State
Diagrams
Diagramas de
Clases
100
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Colaboracin
State
Diagrams
State
Diagrams
Diagramas de
Componentes
Component
Diagrams
Component
Diagrams
Diagramas de
Distribucin
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Estados Diagramas de
Actividad
Modelo
Un modelo es una descripcin completa de un sistema desde una perspectiva concreta
Qu debe aportar un lenguaje de
modelado?
Elementos de modelado Conceptos + Semntica
Notacin Representacin visual de los elementos
Recomendaciones Cmo usarlo
101
Un metamodelo y una semntica
Una notacin grfica
Un conjunto de recomendaciones
Principales elementos de UML:
1.6.2. Arquitectura de UML
18
Arquitectura
Arquitectura de cuatro capas, definida en la
especificacin 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 informacin
Objetos de usuario: define un dominio de
informacin especfico
J erarqua de modelos
104
Los objetos se relacionan con las clases de las que
son creados por la relacin SerInstanciaDe
(IsInstanceOf)
Modelado de objetos
105
Una situacin 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...
City Class
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
Pop = 250M
Area = 200 SM
IsIn
HasRelationship
HasAttribute
HasRelationship
HasAttribute
UML
108
City Class
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
Pop = 250M
Area = 200 SM
IsIn
HasRelationship
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 jerarqua
de instanciacin del clases y objetos
Terminologa de metamodelado...
110
En principio est jerarqua podra continuar hasta
cualquier profundidad arbitraria, pero en la
prctica no se extiende ms all de cuatro niveles
de profundidad
UML se define en cuatro niveles (la gua semntica
de UML representa justamente el nivel meta-
modelo)
Terminologa de metamodelado...
111
...Terminologa de metamodelado
112
1.6.3
Elementos de modelado en UML
Elementos y Relaciones
Diagramas UML
Vistas
UML: Notacin
Bloques
Elementos
Estructurales
De comportamiento
De Agrupacin
114
De Agrupacin
De anotacin
Relaciones
Diagramas
Mecanismos
Mecanismos de Especificacin
Divisiones
Adornos
Mecanismos de extensibilidad
20
Bloques y relaciones
Mtodos
Atributos
Clase
Mtodos
Atributos
Objeto
Estado
Caso de
N d
115
Interfaz
Caso de
Uso
Actor
Nodo
Paquete
Nota Componente
Dependencia Generalizacin
Asociacin Realizacin
Paquetes en UML
Son elementos auxiliares de organizacin y pueden contener
cualquier elemento de modelado.
Pueden anidarse a su vez.
116
Nombre
Nombre Nombre 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
Mtodos
Atributos
Clase
UML- Diagramas
118
Diagramas de estructura
119
Diagramas de comportamiento
120
21
UML- Diagramas
Elicitacin de requisitos de usuario
Casos de Uso
Modelado de la estructura esttica/anlisis y diseo
Diagrama de Clases
Model do de l e t t e tti /implement in
121
Modelado de la estructura esttica/implementacin
Diagrama de Componentes
Diagrama de Distribucin
Modelado de interaccin
Diagrama de secuencia
Diagrama de comunicacin
Modelado dinmico
Diagrama de Estados
Diagrama de Actividades
UML- Casos de uso
Introducido formalmente por Ivar J acobson
De empleo en la etapa de elicitacin para captar los
requisitos de los usuarios
122
De fcil comprensin por parte de los usuarios de los
sistemas
Precisa otras tcnicas complementarias para ser
utilizada en procesos de modelado OO
UML- Casos de uso
incorporar
libros
include
extend
caso de uso
123
realizar
prstamo
Alumno
Bibliotecario
consultar
libro
include
crear nuevo
cdigo
actor
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)
124
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
UML- Diagrama de Clases
Persona
Autor
1..*
1
generalizacin
asociacin
navegabilidad
solicita
125
Alumno
Libro
Prstamo
0..* 0..*
nota
clase
multiplicidad
clase asociacin
solicita
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
126
Permite ver cmo se suceden cronolgicamente los mensajes
entre los objetos
Proviene de los diagramas POSA de Buschmann
Fueron utilizados por los tres autores del UML en sus
respectivos mtodos previos
22
UML- Diagrama de Secuencia
objeto 1 objeto 2 objeto 3
inicio de un mtodo
127
auto-delegacin
destruccin de un
objeto
retorno
activacin
UML- Diagrama de Comunicacin
Es otro de los diagramas de interaccin que se
incluye en el UML
No permite observar grficamente la cronologa de
128
No permite observar grficamente la cronologa de
los mensajes
Facilita la organizacin de los objetos en paquetes
Destaca la conexin esttica entre los objetos
UML- Diagrama de Comunicacin
: Usuario
1: maximo_alcanzado ( )
129
2: ejemplares disponibles ( )
: bibliotecario
: Libro
: Ejemplar
2.1: prestado ( )
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
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
J acobson con la incorporacin de una notacin 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 Actividad
Buscar
transporte
T S
133
Entraasu
trabajo
Cambiade
marcha
Mirapor el
espejo
Tomaun
taxi
Sevaen
su auto
1.6.4
Mecanismos generales de
extensin de UML
Estereotipos.
Restricciones.
Valores etiquetados.
Mecanismos de UML
Tipos de mecanismos
Mecanismos de Especificacin
Completa el aspecto grfico
Divisiones (dicotomas)
Ej: clase y objeto operacin y mtodo
135
Ej: clase y objeto, operacin y mtodo.
Adornos
Se pueden aadir detalles como la multiplicidad de una
relacin
Mecanismos de extensibilidad
Estereotipos
Valores etiquetados
Restricciones (OCL)
Mecanismos de extensin:
Estereotipos
Un estereotipo es un nuevo tipo de elemento de
modelado.
Los estereotipos se representan encerrados en los
smbolos o mediante iconos
136
Mecanismos de extensin:
Valores etiquetados:
Se pueden aadir propiedades a los elementos de
UML. Consisten en parejas de etiqueta + valor
137
Ventana
{abstract,
autor=J os Z.,
estado=comprobada}
Mecanismos de extensin:
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.
138
Todas las restricciones irn siempre encerradas entre
llaves ( { } ).
En particular se puede utilizar OCL (Object Constraint
Language)
24
Persona Comit
Miembro de
Preside
{Subconjunto}
*
*
*
1
Mecanismos de extensin:
Restricciones:
139
{Persona.empleador=
Persona.jefe.empleador}
Persona Empresa
Empleado Empleador
*
0..1
trabajador
jefe
*
0..1
Mecanismos de extensin:
Restricciones: OCL
UML propone un lenguaje para expresar la
navegacin a travs 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 ms a la izquierda
sea un objeto o un conjunto de objetos.
vuelo.piloto.horas_de_entrenamiento >horas.avin.horas_min
empresa.empleado[cargo=Gerenteand Count(Subordinados)>10].
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., J acobson, I., Rumbaugh, J . El Lenguaje Unificado de
Modelado. Gua 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.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
Caso de estudio: Punto de venta
142
Referencia: libro de Larman
Registrar las ventas, incluyendo el detalle de los productos y su
cantidad.
Manejar un catlogo con todos los productos.

Las ventas se registran a travs
de un terminal punto-de-venta (TPDV)
143
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
terminal
Enfoque: Se pretende
independizar las capas del sistema:
Capa de Interfaz
144
Venta Pago
Registro Persistencia
Capa de objetos
del dominio
Capa de servicios
Foco
principal