CUESTIONARIO DE INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS

LECCION PRIMER PARCIAL

LAS RELACIONES QUE SE PUEDEN DAR EN EL DIAGRAMA DE CASOS
DE USO SON:
1. ASOCIACION
2. INCLUSION
3. INTERSECCION
EL MODELO DE ANALIS ESTA COMUESTO POR TRE MODELOS
INDIVIDUALES QUE SON:
1. EL MODELO FUCIONAL
2. EL MODELO DE OBJETOS DE ANALISIS
3. MODELO DINAMICO
EN ANALISIS ORIENTAO A OBJETOS LOS OBJETOS DE FRONTERA:
REPRESENTAN LA INTERACCION ENTRE LOS USUARIOS Y EL SISTEMA
EN ANALISIS ORIENTADO A OBJETOS, LOS OBJETOS DE ENTIDAD:
REPRESENTAN LA INFORMACION PERSISTENTE RASTREADA POR EL SISTEMA
LAS ACTIVIDADES DE DESARROLLO DE INGENIERIA DE SOFTWARE
SON:
a)
b)
c)
d)
e)
f)

OBTENCION DE REQUERIMIENTOS
ANALISI
DISENO
DESARROLLO
PRUEBAS
IMPLEMENTACION

ACERCA DE LOS DIAGRAMAS DE CASOS DE USO SE PUEDE DECIR

QUE:
SE UTILIZAN DURANTE LA OBTENCION DE REQUERIMIENTOS Y EL ANALISIS
PARA REPRESENTAR A FUNCIONALIDAD DEL SISTEMA
UNA CLASE SE PUEDE DEFINIR COMO
UNA ABSTRACCION ESPECFICA LA ESTRUCTURA Y EL COMPORTAMIENTO
COMUN DE UN CONJUNTO DE OBJETOS
ES UN CONJUNTO ORGANIZADI DE PARTES QUE SE COMUNICAN,
DISEADO PARA UN PROPOSITO ESPECIFICO.
SISTEMA
EN INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS, EL AUTOR
CONSULTADO CLASIFICA LOS REQUERIMIENTOS EN :
1. FUNCIONALES
2. NO FUNCIONALES
3. SEUDO REQUERIMIENTOS

ALGUNAS DE LAS ACTIVIDADES DESARROLLADAS EN LA ETAPA DE

OBTENCION DE REQUERIMIENTOS SON :
1. IDENTIFICACION DE LOS ACTORES
2. IDENTIFICACION DE ESCENARIO
3. IDENTIFICACION DE CASOS DE USO
REALIZAR LOS DIAGRAMAS DE CASOS DE USO PARA EL PROBLEMA
PROPUESTO

Una biblioteca tiene copias de libros. Estos ltimos se caracterizan por su

nombre, tipo (novela, teatro, poesa, ensayo), editorial, ao y autor.

Los autores se caracterizan por su nombre, nacionalidad y fecha de

nacimiento.

Cada copia tiene un identificador, y puede estar en la biblioteca, prestada, con

retraso o en reparacin.

Los lectores pueden tener un mximo de 3 libros en prstamo.

Cada libro se presta un mximo de 30 das, por cada da de retraso, se impone

una multa de dos das sin posibilidad de coger un nuevo libro.

Realiza un diagrama de clases y aade los mtodos necesarios para realizar el

prstamo y devolucin de libros.

LECCION PRIMER PARCIAL

LA INGENIERIA DE SOFTWARE SE LA PUEDE DESCRIBIR COMO :
UNA ACTIVIDAD DE MODELADO
UNA ACTIVIDAD PAR LA SOLUCION DE PROBLEMAS
UNA ACTIVIDAD PARA LA ADQUISIOND DE CONOCIMIENTO
LOS DIAGRAMAS DE CLASE SE DESCRIBEN:
2

El sistema desde el punto de vista de objetos, clases, atributos, operaciones

y sus asociaciones. Por ejemplo, la figura 2-2 es un diagrama de clase que
describe los elementos de todos los relojes de la clase RelojSimple . Todos
estos objetos de reloj tienen una asociacin con un objeto de la clase
BotnOprimible , un objeto de la clase Pantalla , un objeto de la clase Hora y
un objeto de la clase Batera .
LOS DIAGRAMAS DE SECUENCIA SE PUEDE DECIR QUE:
Se usan para formalizar el comportamiento del sistema y para visualizar la
comunicacin entre objetos.
Son tiles para la identificacin de objetos adicionales que participan en los
casos de uso.
Un diagrama de secuencia representa las interacciones que suceden entre
esos Objetos.
LOS DIAGRAMAS DE GRAFICA DE ESTADO DESCRIBEN:
El comportamiento de un objeto individual como varios estados y
transiciones entre esos estados.
ES UN CONJUNTO ORGANIZADO DE PARTES QUE SE COMUNICAN,
DISENADO PAR UN PROPOSITO ESPECIFICO.
SISTEMA
LECCION DEL PRIMER PARCIAL
SON REQUERIMIENTOS IMPUESTOS
RESTRINGEN LA IMPLEMENTACION

POR

EL

CLIENTE

QUE

DEL SISTEMA.
LOS PSEUDOREQUERIMIENTOS
ES UNA DESCRIPCION NARRATIVA DE LO QUE LA GENTE HACE Y
EXPERIMENTA
CUANDO
TRATA
DE
UTILIZAR
SISTEMAS
Y
APLICACIONES DE COMPUTADORA. SE REFIERE
ESCENARIOS
ACERCA DE LOS CASOS DE USO SE PUEDE DECIR QUE :
ESPECIFICA TODOS OS ESCENARIOS POSIBLES PARA UNA PATE DE
FUNCIONALIDAD DADA
ES INICIADO POR UN ACTOR
UNA VEZ INICIADO PUEDE INTEREACTUAR CON OTROS ACTORES
REPRESENTA UN FLUJO DE EVENTOS COMPLETOS A TRAVES DEL SISTEMA
LAS RELACIONES ENTRE LOS ACTORES Y CASOS DE USO PUEDEN
SER:

Las relaciones entre actores y casos de uso permiten que los

desarrolladores y usuarios reduzcan la complejidad del modelo e
incrementen su comprensibilidad.
Las relaciones de comunicacin entre actores y casos de uso para describir
el sistema en capas de funcionalidad.
Usamos relaciones extendidas para separar el flujo comn de eventos del
excepcional. Usamos relaciones de inclusin para reducir la redundancia
entre casos de uso.
LOS REQUIRIMIENTOS QUE DESCRIBEN LAS INTERACCIONES ENTRE
EL SISTEMA Y SU AMBIENTE EN FORMA INDEPENDIENTE A SU
IMPLEMENTACION SON:
LOS REQUERIMIENTOS FUNCIONALES
DESCRIBEN ASPECTOS DEL SISTEMA VISIBLES POR EL USUARIO QUE
NO SE RELACIONAN EN FORMA DIRECTA CON EL COMPORTAMIENTO
FUNCIONAL DEL SISTEMA.
LOS REQUERIMIENTOS NO FUNCIONALES
EN
LA
OBTENCION
DE
REQUERIMEINTOS,
PARTICIPANTES CORRESPONDEN A:

LOS

OBJETOS

TODOS LAS ENTIDADES QUE COMPONEN EL SISTEMA

REGISTRO
FUNCIONAL
,
NO
FUNCIONAL
O
PSEUDOREQUERIMIENTO SEGN CORRESPONDA EN CADA UNO DE
LOS SIGUIENTES REQUERIMIENTOS DE UN SISTEMA.
1. EL SISTEMA ESTA DESARROLLADO CON HERRAMIENTAS OPEN
SOURCE P REQ
2. EL SISTEMA DEBERA RESPONDER INMEDIATAMENTE A LOS
REQUERIMIENTOS F
3. EL SISTEMA PERMITIRA REGISTRAR DIFERENTES ROLES A
DIFERENTES USUARIOS
4. EL SISTEMA CALCULARA EL DESCUENTO EN CADA COMPRA
SEGN EL PORCENTAJE CONFIGURADO PARA CADA CLIENTE F
5. EL SISTEMA WEB ESTARA REALIZADO CON HTML NF
6. EL SISTEMA MANTENDRA LA SEGURIDAD DE OS DATOS
ALMACENADOS
7. EL SISTEMA DEBE CALCULAR EL 12 % DE IVA EN BASE AL
SUBTOTAL
8. EL SISTEMA DEBERA TENER EL LOGOTIVO DE LA EMPRESA EN
LA PARTE SUPERIOR DERECHA
9. EL SISTEMA PERMITIRA REGISTRAR A LOS CLIENTES EN LA
BASE DE DATOS
10.
EL SISTEMA CALCULAR UN PORCNTAJE DE DESCUENTO A
LOS CLIENTES HABITUALES
UNA ESPECIFICACION DEL SISTEMA ES RASTREABLE SI
CADA FUNCION DEL SISTEMA PUEDE RASTREARSE HASTA SU CONJUNTO DE
REQUERIMIENTOS CORRESPONDIENTE
4

LA VALIDACION DE REQUERIMIENTOS INVOLUCRA LA REVISION PARA

VER SI LA ESPECIFICACION ES
LA VALIDACIN DE REQUERIMIENTOS INVOLUCRA LA REVISIN PARA VER SI
LA ESPECIFICACIN ES CORRECTA, COMPLETA, CONSISTENTE, REALISTA Y
NO ES AMBIGUA.
EXAMEN DE SEGUNDO PARCIAL
EL DISEO DE SISTEMA DA COMO RESULTADO
Una lista de objetivos de diseo que describe las cualidades del sistema
que deben optimizar los desarrolladores.
Una arquitectura de software que describe la descomposicin en
subsistemas desde el punto de vista de responsabilidades del subsistema,
dependencias entre subsistemas
LA ARQUITECTURA DE SOFTWARE SE REFIERE A:
La descomposicin del sistema, el flujo de control global, las polticas de
manejo de errores y tos protocolos de comunicacin.
ACERCA DE LAS CAPAS Y PATICIPACIONES DE UN SUBSISTEMA SE
PUEDE DECIR QUE:
El objetivo del diseo del sistema es manejar la complejidad dividiendo
el sistema en partes ms manejables. Esto puede lograrse mediante un
enfoque de dividir y conquistar, en donde dividimos las partes en forma
reiterada hasta que son lo bastante simples para ser manejadas por una
persona o un equipo. La aplicacin sistemtica de este enfoque conduce a
una descomposicin jerrquica en la cual cada subsistema, o capa,
proporciona servicios de nivel ms alto usando servicios proporcionados por
subsistemas de nivel inferior.
SEGN EL PMI, LA DIRECION DE PROYECTOS SE LOGRA MEDIANTE
LA APLICACIN DE 47 PROCESOS AGRUPADOS EN CINCO GRUPOS
DDE PROCESOS QUE SON:
INICIACION, PLANIFICACION, EJECUCION, SEGUIMIENTO Y CONTROL.
PMI DEFINE UN PROYECTO COMO:
ES UN ESFUERZO TEMPORAL QUE SE LLEVA A CABO PARA CREAR UN
PRODUCTO, SERVICIO O RESULTADO UNICO.
EN LA ARQUITECTURA DE LOS SISTEMAS DE COMPUTACION, LA
ARQUITECTURA DE DEPSITO SE DEFINE COMO:
Los subsistemas acceden y modifican datos de una sola estructura de datos
llamada depsito central.
LA DIRECCION DE UN PROYECTO ES :
LA APLICACIN DE CONOCIMIENTOS, HABILIDADES, HERRAMIENTAS Y
TECNICAS A LAS ACTIVIDADES DEL PROYECTO PARA CUMPLIR CON LOS
REQUISITOS DEL MISMO
5

ES LA PERSONA ASIGNADA POR LA ORGANIZACIN EJECUTANTE

PARA ALCANZAR LOS OBJETIVOS DEL PROYECTO
DIRECTOR DE PROYECTO
SON
PEROSONAS
U
ORGANIZACIONES
QUE
PARTICIPAN
ACTIVAMENTE EN EL PROYECTO O CUYOS INTERES PUEDEN VERSE
AFECTADOS POSITIVA O NEGATIVAMENTE POR EJECUCION O
TERMINACION DEL PROYECTO
INTERESADOS
EL DOCUMENTO OFICIAL QUE AUTORIZ EL INICIO DEL PROYECTO ES:
ACTA DE CONSTITUCION DEL PROYECTO
EXAMEN DEL SEGUNDO PARCIAL
EN DISENO DE SISITEMAS EL ACOPLAMIENTO SE REFIEREA A:
ES LA FUERZA DE LA DEPENDENCIAS ENTRE DOS SUBSISTEMAS
EN DISENO DE SISTEMAS LA COHERENCIA SE REFIERE A:
ES LA FUERZA DE LAS DEPENDENCIAS DENTRO DE UN SUBSISTEMA
LAS PRUEBAS SE PUDEN DEFINIR COMO:
ES EL PROCESO DE ANALISIS DE UN SISTEMA, O COMPONENTE DE UN
SISTEMA, PARA DETECTAR LAS DIFERENCIAS ENTRE EL COMPORTAMIENTO
ESPECIFICADO (REQUERIDO) Y EL OBSERVADO (EXISTENTE).
LOS TIPOS DE PRUEBAS, SEGN SU
CLASIFICAR EN TRES GRUPOS QUE SON:

ALCANCE,

SE

PUEDEN

PRUEBAS UNITARIAS
PRUEBAS DE INTEGRACION
PRUEBAS DE SISTEMA
ESCRIBA EN LA SEGUNDA COLUMNA EL ITEM DE LA TERCERA
COLUMNA QUE CORRESPONDA AL CONCEPTO PLANTEADO.
ES UNA PARTE DEL SISTEMA QUE PUEDE AISLARSE PARA LA PRUEBA. UN
COMPONENTE PUEDE SER UN OBJETO, UN GRUPO DE OBJETOS O UNO O
MAS SUBSISTEMAS
ES UN ERROR DE DISENO O CODIFICACION QUE PUEDE CAUSAR UN
COMPORTAMIETO ANORMAL DE UN COMPONENTE.
ES LA MANIFESTACION DE UN DEFECTO DURANTE LA EJECUCION DEL
SISTEMA.
ES UNA DESVIACION ENTRE LA ESPECIFICACION DE UN COMPONENTE Y SU
COMPORTAMIENTO. UNA FALLA ES PRODUCCIDA POR UNO O MAS ERRORES

ES UN CONJUNTO DE ENTRADAS Y RESULTADOS ESPERADOS QUE EJERCITA

A UN COMPONENTE CON EL PROPOSITO DE CAUSAR FALLAS Y DETECTAR
DEFECTOS
EN CUANTO A LAS PRUEBAS UNITARIAS SE PUEDE DECIR QUE:
Se enfoca en los bloques de construccin del sistema de software; esto es,
los objetos y subsistemas.
Reduce la complejidad de las actividades de prueba generales.
Resaltar y corregir defectos, ya que estn involucrados pocos componentes.
Permite el paralelismo en las actividades de prueba
LA DIRECCION DE PROYECTO ES:
LA APLICACIN E CONOCIMIENTO, HABILIDADES, HERRAMIENTAS Y
TECNICAS A LAS ACTIVIDADES DEL PROYECTO PARA CUMPLIR CON LOS
REQUISITOS DEL MISMO.
EN LA PRUEBA DE SISTEMAS HAY VARIAS ACTIVIDADES QUE SE
DEBEN REALIZAR
PRUEBA DE FUNCION
PRUEBA DE DESEMPENO
PRUEBA DE ACEPTACION
PRUEBA DE INSTALACION