ClaseAyD_11.pptx

8/8/2019 ClaseAyD_11.pptx

1/84

ANALISIS Y DISEO DESISTEMAS

SESION 11

UNIVERSIDAD NACIONAL DE INGENIERIAFacultad de Ingeniera Industrial y de SistemasIng. Jess Walter Antaurco Trujillo

[email protected] 1


2/84

Objetivos de la clase Definir el modelamiento de

requisitos.

Entender la fase parte 1 de anlisis

(ejemplo de requisitos)

2


3/84

Contenidos

1. Modelamiento de Requisitos

2. Resumen de la fase de requisitos

3


4/84

Modelado de Requisitos

4


5/84

Artefacto Pieza de informacin utilizada o producida por un

proceso de desarrollo de software

Artefactos implicados durante la captura de

requisitos

Modelo de Casos de Uso

Actor

Glosario

Caso de Uso

Prototipo de Interfaz de Usuario

Descripcin de la Arquitectura

n

5


6/84

Work Flow de Requisitos

Analista de Sistemas

Arquitecto

Especificador CU

Diseador de Interfaz

de usuario Prototiparla Interfaz de Usuario

Detallarlos Casos de Uso

Priorizarlos Casos de Uso

Encontrar Actoresy Casos de Uso

Estructurar el Modelode Casos de Uso

6


7/84

Modelado de Requisitos

Objetivo:

Establecer los requisitos funcionales y nofuncionales del sistema.

A partir del modelo del negocio (si se hace)

se construye el modelo de casos de uso yel modelo conceptual.

7


8/84

Qu es un Requerimiento ?

RAE (Real Academia de la Lengua Espaola)

Requerimiento

Accin y efecto de requerir.

Requisito

Circunstancia o condicin necesaria paraalgo.

8


9/84

Qu es un Requerimiento ?

Un requerimiento es una condicin o capacidada la que el sistema (siendo construido) debe

conformar [ Rational Software Corp.].

Un requerimiento de software puede serdefinido como :

Una capacidad del software necesaria por el usuariopara resolver un problema o alcanzar un objetivo. Una capacidad del software que debe ser reunida o

poseda por un sistema o componente del sistema parasatisfacer un contrato, especificacin, estndar, u otra

documentacin formal. [Somerville] 9


10/84

Interpretaciones acerca de los

Requerimientos El consultor Brian Lawrence sugiere que un

requerimiento es cualquier cosa que impulsa un diseode calidad. Muchos tipos de informacin caen en estacategora.

El glosario estndar IEEE de Terminologa de Ingenierade Software define un requerimiento como:

1. Una condicin o capacidad necesaria por un usuario para resolver unproblema o lograr un objetivo.

2. Una condicin o capacidad que debe ser cumplida o poseda por unsistema o componente del sistema para satisfacer un contrato,estndar, especificacin u otros documentos formalmente impuestos.

3. Una representacin documentada de una condicin o capacidad comoen las especificaciones 1 o 2.

10


11/84

Qu representan y muestran los

Requerimientos ?

Los requerimientos de usuario representanLos requerimientos de usuario representanel conjunto completo de resultados a serel conjunto completo de resultados a ser

obtenidos utilizando el sistema.obtenidos utilizando el sistema. Los requerimientos de sistemas debenLos requerimientos de sistemas deben

mostrar todo lo que el sistema debe hacermostrar todo lo que el sistema debe hacermas todas las restricciones sobre lamas todas las restricciones sobre la

funcionalidad.funcionalidad. Los requerimientos forman un modeloLos requerimientos forman un modelo

completo, representando el sistema total acompleto, representando el sistema total aalgn nivel de abstraccin.algn nivel de abstraccin.

11


12/84

Rol de Requerimientos

Si un producto no es lo que el cliente o los usuariosquieren, entonces la calidad de la construccin es

irrelevante. El rol clave de los requerimientos es mostrar a los

desarrolladores y usuarios que se necesita de unsistema.

Proveer los requerimientos forma parte de un

lenguaje que todos comprenden, ya que todos estninvolucrados, incluyendo los clientes. El primer y bsico rol de los requerimientos es por lo

tanto la comunicacin.

12


13/84

Cmo identificamos losCmo identificamos los

Requerimientos ?Requerimientos ?

Los Requerimientos toman vida desde querealizamos nuestro primer encuentro de

interlocucin con usuarios o clientes. Este puede desarrollarse utilizando cualquiera

de una variedad de tcnicas como entrevistaspara intercambiar opiniones, brainstorming,

prototipeo, cuestionarios, etc. Cuando los requerimientos se logran redactar

a un significativo nivel de detalle, tendremoslisto el documento denominado Especificacin

de Requerimientos. 13


14/84

Buena Especificacin de

Requerimientos Un resultado primario es la Especificacin de

Requerimientos, la cual define y documenta

en forma completa el comportamientoexterno del sistema a ser construido.Caracterizndose por : Definidos sin ambigedad Son completos Tienen consistencia Especifica el origen Evita detalles de diseo Estn enumerados

14


15/84

Beneficios de una Buena Gestin

de Requerimientos

Mejor control de proyectos complejos.

Mejora en la calidad del software y en lasatisfaccin del cliente. Reduccin en los retrasos y en los costos

del proyecto. Mejora en la comunicacin del equipo. Facilita la conformidad con estndares y

regulaciones.

15


16/84

Los Problemas de la Gestin de

Requerimientos No son siempre obvios y tienen muchas fuentes. No son siempre fciles de expresar en palabras.

Hay muchos tipos diferentes a distintos niveles dedetalle. El nmero puede llegar a ser inmanejable. Estn relacionados a otros en una variedad de

formas.

Hay muchos interesados y partes responsables. Cambian. Pueden ser sensibles al tiempo.

16


17/84

El Alto Costo de Errores en los

Requerimientos

Hay fuertes evidencias que una efectivaadministracin de requerimientos conducen a

los ahorros del proyecto integral. Las tres razones primarias para esto son :

Costos de reparar errores en los requerimientossuperan en mas de 10 veces a otros errores.

Errores de requerimientos comprenden encima del40% de todos los errores de un proyecto desoftware.

Pequeos reducciones en el nmero de errores derequerimientos rinden grandes dividendos al evitar

costos de re-trabajo y das de retraso. 17


18/84

Los valos representan tipos de requerimientos de informacin y los

rectngulos indican contenedores o recipientes (documentos, diagramas o

bases de datos) en la cual almacenamos esta informacin.

NIVELES DE LOS REQUERIMIENTOS

18


19/84

Requerimientos del Dominio

Se derivan del dominio del sistema ms que delas necesidades especficas de los usuarios.

Pueden ser requerimientos funcionales nuevos,restringir los existentes o establecer cmo sedeben ejecutar clculos particulares.

Los requerimientos del dominio son importantes

debido que a menudo reflejan los fundamentosdel dominio de aplicacin. Si estos requerimientos no se satisfacen, es

imposible hacer que el sistema trabaje de forma

satisfactoria. 19


20/84

Requerimientos de Usuario Describen las metas del usuario o las tareas

que los usuarios deben ser capaces de

ejecutar con el producto. Formas valiosas para representar los

requerimientos de usuario incluyen a loscasos de uso, descripciones de escenarios, ytablas de respuesta a eventos.

Los requerimientos de usuario sin embargodescriben lo que el usuario ser capaz dehacer con el sistema.

20


21/84

Requerimientos del Sistema

Establecen con detalle los servicios yrestricciones del sistema.

El documento de requerimientos del sistema,algunas veces denominado especificacinfuncional, debe ser preciso.

ste sirve como parte del contrato entre elnegocio y el desarrollador de software.

21


22/84

Ej. Definicin de

Requerimientos de Usuario

1.El software debe proveer un mediopara representar y acceder a archivosexternos creados por otrasherramientas.

22


23/84

Ej. Especificacin deRequerimientos del sistema

1.1 Al usuario se le proveer con los recursos para definirel tipo de archivos externos.

1.2 Cada tipo de archivo externo tendr una herramientaasociada que ser aplicada al archivo.1.3 Cada tipo de archivo externo se representar como un

icono especifico sobre la pantalla del usuario.1.4 Se proveern recursos para que el usuario defina el

icono que representa un tipo de archivo externo.1.5 Cuando un usuario selecciona un icono que representa

un archivo externo, el efecto de esa seleccin esaplicar la herramienta asociada con este tipo de archivoal archivo representado por el icono seleccionado.

23


24/84

Tipos de Requisitos Funcionales

Que tienen que ver con la funcionalidad del sistema Describen lo que el Sistema debe hacer

No Funcionales Usabilidad Fiabilidad Rendimiento Adaptabilidad, Mantenimiento, Configurable Implementacin: lenguajes, herramientas,.. GUI Legales 24


25/84

Requerimientos Funcionales Describen la funcionalidad o los servicios que se

espera proveer el sistema.

Estos dependen del tipo de software y delsistema que se desarrolle y de los posiblesusuarios del software.

Cuando se expresan como requerimientos del

usuario, habitualmente se describen de formageneral mientras que los requerimientosfuncionales del sistema describen con detalle lafuncin de ste, sus entradas y salidas,excepciones, etc.

25


26/84

Requerimientos no funcionales

26


27/84

RNF Requerimientos del

Producto

stos especifican el comportamiento delproducto.

Algunos ejemplos son los requerimientos dedesempeo en la rapidez de ejecucin delsistema y cunta memoria se requiere; los de

fiabilidad que fijan la tasa de fallas para queel sistema sea aceptable; los de portabilidad ylos de usabilidad.

27


28/84

RNF: Requerimientos

Organizacionales

Se derivan de las polticas y procedimientosexistentes en la organizacin del cliente y en

la del desarrollador. Algunos ejemplos son los estndares en los

procesos que deben utilizarse; Los requerimientos de implementacin como los

lenguajes de programacin o el mtodo de diseoa utilizar, y los requerimientos de entrega queespecifican cundo se entregar el producto y sudocumentacin.

28


29/84

RNF: Requerimientos Externos Este gran apartado cubre todos los requerimientos

que se derivan de los factores externos al sistema yde su proceso de desarrollo.

stos incluyen los requerimientos deinteroperabilidad que definen la manera en que elsistema interacta con los otros sistemas de laorganizacin; los requerimientos legales que debencumplirse para operar dentro del marco de la Ley, ylos requerimientos ticos que permitan asegurar queser aceptado por el usuario y por el pblico engeneral.

29


30/84

Ejemplos RNF Requerimiento del Producto

El tiempo de respuesta que debe ofrecer el sistema parauna transaccin en el mdulo X debe oscilar entre los 3 y 6seg.

Requerimiento Organizacional El proceso de desarrollo del sistema y los documentos a

entregar debern apegarse al proceso y a los productos aentregar definidos en la norma N abc-2002.

Requerimiento Externo El sistema no deber revelar a sus operadores alguna

informacin personal de los clientes excepto su nombre ynmero de referencia.

30


31/84

Del modelo de negocio al

modelo de requisitos Extraer los casos de uso del sistema a

partir de las actividades que aparecen enlos diagramas de actividades.

Establecer el modelo conceptual apartir de las informaciones incluidas en los

diagramas de actividades.

31


32/84

actor

Del modelo de negocio al modelo

de requisitos De los diagramas de proceso...

Concepto delDominio

Caso de Uso

objeto

actividad

rol

32


33/84

Diagrama de Casos de Uso Registrar Pedido

Analizar Produccion

Ordenar Fabricacion

JefeTecnico

Introducir Pedido

Cliente

Informar Pedido

Cursar Pedido

JefeProduccionPlanificar Produccion

Comercial

33


34/84

Identificacin de casos de uso Objetivos Estrtegicospcasos de uso del

negocio Ejemplo: Evitar prdidas

Objetivos de Usuariop casos de uso Ejemplo: Realizar Venta

Subfuncionesp

casos de uso? Ejemplo: Iniciar sesin (Login)

34


35/84

Identificacin de casos de uso

Establecer los lmites del sistema Identificar los actores principales

Es el cliente un actor en el sistema Terminal Puntode Venta?

Identificar sus objetivos de usuario Posible uso de los eventos externos

Definir un caso de uso por objetivo de usuario Excepcin: casos de uso para manejar informacin

(crear, eliminar, modificar, consultar)

Formato expandido y esencial35


36/84

Plantilla usecases.org Actor Principal Personas involucradas e Intereses

Precondiciones Postcondiciones Escenario Principal (Flujo Bsico) Extensiones (Flujos Alternativos)

Requisitos especiales Tecnologa y Lista Variaciones de datos Frecuencia Cuestiones abiertas

36


37/84

Ejemplo: Terminal Punto de Venta

Casos de Uso

Cajero

Realizar Venta

Cliente

Registrar Productos

IniciaGerente

Gestion UsuariosAdministrador

Sistema

37


38/84

Caso de uso Realizar Venta

Resumen:Un cliente llega al TPV con un conjunto de artculos. ElCajero registra los artculos y se genera un ticket. El cliente paga enefectivo y recoge los artculos.

Actor Principal: CajeroPersonal Involucrado e Intereses: Cajero: quiere entradas precisas, rpida y sin errores de pago Compaa: quiere registrar transacciones y satisfacer clientes. ...

Precondicin: El cajero se identifica y autentica Postcondiciones: Se registra la venta. Se calcula el

impuesto. Se actualiza contabilidad e inventario...

38


39/84


Flujo Bsico:1. A: El cliente llega al TPV con los artculos.2. A: El cajero inicia una nueva venta

3. A: El cajero introduce el identificador de cada artculo.4. S: El sistema registra la lnea de venta y presenta descripcin delartculo, precio y suma parcial.

El Cajero repite los pasos 3 y 4 hasta que se indique.5. S: El Sistema presenta el total

6. A: El Cajero le dice al Cliente el total a pagar7. S: El Cliente paga y el sistema gestiona el pago.8. S: El Sistema registra la venta completa y actualiza Inventario.9. S: El Sistema presenta recibo

39


40/84


Extensiones (Flujos Alternativos):3a. Identificador no vlido

1. El Sistema seala el error y rechaza la entrada

3-6a. El Cliente pide eliminar un artculo de la compra1. El Cajero introduce identificador a eliminar2. El sistema actualiza la suma

...7a. Pago en efectivo

1. El Cajero introduce cantidad entregada por el cliente2. El Sistema muestra cantidad a devolver...

....

40


41/84

Caso de uso Realizar VentaRequisitos especiales:

- Interfaz de usuario con pantalla tctil en un monitor de pantallaplana. El texto debe ser visible a un metro de distancia.

- Tiempo de respuesta para autorizacin de crdito de 30 sg. El 90%de las veces...

Lista de Tecnologa y Variaciones de Datos:- El identificador podra ser cualquier esquema de cdigo UPC, EAN,..

- La entrada de informacin de la tarjeta se realiza mediante un lectorde tarjetas....

Cuestiones Pendientes:- Explorar cuestiones de recuperacin de accesos a servicios remotos- Qu adaptaciones son necesarias para diferentes negocios?

41


42/84

Diagramas de estado de casos

de uso

Es r

tI tr ci

Artic l s

cr r t

i t r cirArt ic l

Es r

fi liz r t

A t riz

r liz r EnEf ct i

r liz r A r it

r liz r nCheque

Procesar Venta

42


43/84

Elaboracin de casos de uso Cundo?

Al principio de la iteracin en formato extendido yesencial, se refinan a lo largo de las iteraciones

Dnde? En talleres de captura de requisitos

Quin? Usuarios finales, clientes, desarrolladores

Cmo? (Herramientas) Herramientas de requisitos web-enabled integradas

con un procesador de texto (texto cdu) yherramientas CASE UML (diagramas de cdu)

43


44/84

Recomendaciones sobre casos

de uso Define bien los lmites del sistema. Los actores interaccionan con el sistema. Pregunta qu quieren los actores del sistema:Objetivos.

Distingue el flujo normal de los flujos alternativos.

Lo importante es escribir la descripcin del casode uso, no dibujar diagramas de casos de uso. Uso limitado de las relaciones include y extend

44


45/84

Recomendaciones sobre casos

de uso Usa include para factorizar parte de un flujo que

aparece en varios casos de uso.

Las extensiones pueden incluirse dentro del casode uso base como flujos alternativos en vez deincluir casos de uso aparte.

El propio sistema puede disparar casos de uso.

No incluir casos de uso CRUD; casos de uso Creary Consulta si son relevantes. No especificar casos de uso que incluyan detalles

de diseo de interfaces de usuario.

45


46/84

Modelo Conceptual (o Dominio)

Representa el vocabulario del dominio:ideas, conceptos, objetos

No son modelos de elementos software Clases conceptuales Clases no incluyen operaciones, slo

atributosAtributos: nmeros o textoAsociaciones entre clases

46


47/84

IdentificarClases Conceptuales

Si se hace modelado del negocio:Los objetos informacin, entrada y salida de lasactividades de los diagrama de proceso, representan

entidades y conceptos del dominio. Una clase conceptual para cada informacin

relevante. De la especificacin del diccionario se extraen:

atributos, asociaciones, restricciones Se refina a lo largo de las iteraciones Ms vale que sobren clases que falten

47


48/84

Del Modelo del Negocio al

Modelo ConceptualObjeto informacin Pedido(modelodelnegocio)

Atributos: codigo, importe, estado, fechaTopeEntrega,..

Asociaciones: Pedido-Cliente yPedido-Producto,..

Restricciones: fechaTopeEntrega > fechaRecepcion, ..

Tambin es posible identificar objetos que pasan por

varios estados (diagramadeestados preliminar)

48


49/84


Si no se hace modelado del negocio: Usar una lista de categoras de clases

Identificar nombres de las frases Categoras de clases

Objetos fsicos Especificaciones o descripciones de cosas Lugares Transacciones Lneas de una transaccin

49


50/84


Categoras de clases (continua) Contenedores de cosas Cosas en un contenedor Dispositivos externos al sistema Conceptos abstractos Eventos Procesos

Reglas y Polticas Catlogos Contratos, documentos legales Instrumentos y servicios financieros Manuales, documentos, trabajos, libros

50


51/84

Modelo Conceptual

Gerente

Cajero

PagoCliente

TPV

11 11

Iniciado por

1

1

1

1

Registra Ventas

Venta

1

1

1

1pagado por

1

1

1

1iniciada por

11

11

capturada en

Catalogo Productos

Tienda

direccionnombre

Lineas Venta

cantidad

1..n

1

1..n

1

Contenidas en

Producto

1..n1 1..n1

Contiene

1

0..n

1

0..n

Descrita por

Item0..n1 0..n1

Almacena 1

0..1

1

0..1

Registra venta de

0..n0..n

Describe1

0..n

1..n

1

Usado-por

51


52/84

Modelo conceptual inicial

Modelo

PropioEnCatalogo

Cliente Pedido

1..n1 1..n1

1

1

1

1

Plantilla

11 11

EspecificacinTarea

OrdenTarea

Puesto Produccin

1

0..n

1

0..n

Material

LineaMaterial

Tarea1..n1..n

11

1

1

1

111..n 11..n

52


53/84

Identificar Asociaciones Se incluyen aquellas:

para la que el conocimiento de la relacin debe

mantenerse algn tiempo derivadas de la Lista de Asociaciones

Lista de Asociaciones A es parte fsica de B

A es parte lgica de B A est fsicamente contenida en B A est lgicamente contenida en B A es una descripcin de B

53


54/84

Identificar Asociaciones Lista de Asociaciones (continua)

A es una lnea de una transaccin o informe B A es conocido/registrado/informado/capturado en B A es miembro de B A es una subunidad organizacional de B A usa o maneja a B A comunica con B A est relacionado a una transaccin B A es el siguiente a B A es apropiado por B A es un evento relacionado con B

54


55/84

Identificar AsociacionesEncontrar clases conceptuales es ms importanteque encontrar asociaciones. Se debe dedicar mstiempo a encontrar clases conceptuales que

asociaciones

Centrarse en las asociaciones necesita-conocer Muchas asociaciones dificultan la comprensin de los

diagramas Evitar asociaciones redundantes En la implementacin se notar que falta o sobra

alguna asociacin

55


56/84

Asociaciones en TPV A es parte fsica de B

TPV-Caja

A es parte lgica de B LineaVenta-Venta

A est fsicamente contenida en B Item-Tienda, TPV-Tienda

A est lgicamente contenida en B EspecificacionProducto-CatalogoProductos

A es una descripcin de B EspecificacionProducto-Item

56


57/84

Asociaciones en TPV A es una lnea de una transaccin o informe B

LineaVenta-Venta A es conocido/registrado/informado/capturado en B

Venta-TPV A es miembro de B

Cajero-Tienda A usa o maneja a B

Cajero-TPV, Gerente-TPV A comunica con B

Cliente-Cajero

A est relacionado a una transaccin B Cliente-Pago, Cajero-Pago A es el siguiente a B

LineaVenta-LineaVenta A es apropiado por B

TPV-Tienda

57


58/84

Atributos Son valores de tipos de datos: Identidad no tiene sentido Tipos Primitivos: Boolean, Date, Numero, Time, String Tipos no primitivos: Direcciones, Colores, Nmero Tlfno,

Nmero Seguridad Social, DNI, Cdigo de ProductoUniversal, Cdigo Postal,..

Tipos no primitivos se deben modelar como clases si: Estn formados por varias partes

Son aplicables las operaciones Tiene otros atributos Es una cantidad con una unidad

No utilizar atributos como claves ajenas

58


59/84

Documentos de Anlisis Requisitos Casos de Uso Especificacin Complementaria

Captura otros requisitos Glosario

Captura trminos y definiciones

Visin Define visin del producto de las personas

involucradas, en trminos de sus necesidades ycaractersticas.

59


60/84

Especificacin Complementaria Funcionalidad

Abarca varios casos de uso Ej. Almacenar informacin errores, Cualquier uso requiere

autenticacin de usuario RequisitosNo Funcionales(Atributosde calidad)

Usabilidad, Mantenimiento, Adaptacin, Fiabilidad, Rendimiento Restricciones Implementacin (hardware, software, desarrollo) Componentes comprados y free open source

Interfaces Reglas de Negocio (Ej. Reglas de descuento, Clculo impuestos) Cuestiones Legales Cuestiones sobre el entorno fsico y operacionales Informacin en dominios relacionados

60


61/84

Visin Oportunidad Definicin del problema Alternativas Descripcin personal involucrado (stakeholder) Objetivos usuario Perspectiva del producto Beneficios del producto Lista de caractersticas del producto Coste y precio Otros requisitos y restricciones

61


62/84

Lista de Caractersticas del

Sistema Alguna funcionalidad no puede ser asignada a un

caso de uso:

El sistema debe hacer transacciones con sistemasexternos de inventario, contabilidad y clculo deimpuestos

Para algunas aplicaciones conviene ms una listade caractersticas que casos de uso Ej. Servidor de aplicacin

62


63/84

Qu hacemos primero?1. Escribir un borrador poco elaborado de la Visin

en la Etapa Inicial

2. Identificar objetivos del usuario y casos de usopara ellos3. Escribir algunos casos de uso y comenzar

Especificacin Complementaria

4. Refinar Visin

63


64/84

Elaboracin de Requisitos y Visin Cundo?

Etapa Inicial, un poco Modelado de requisitos en cada iteracin

Dnde? Inicio en talleres de requisitos, se completa despus

Quin?

Analista de sistemas, Arquitecto Software, Usuarios Cmo?

Herramientas de requisitos web-enabled integradascon un procesador de texto

64


65/84

Casos de uso e iteraciones

Asignar prioridad a casos de uso Escribir casos de uso en su forma expandida Asignar casos de uso a iteraciones. Varias versiones de un caso de uso complejo,

para aadir complejidad de modo incremental.

Necesidad de comunicacin con el usuario Al final un caso de uso esencial se transforma

en su forma concreta.

65


66/84

Iteraciones Dirigidas por el riesgo

Asociar a cada caso de uso un nivel de riesgo e

importancia para el negocio Comenzar pronto con la programacin Realizar pruebas Rpida retroalimentacin Se obtiene la arquitectura en las primeras

iteraciones

66


67/84

Prototipo Inicial

Utilizar los casos de uso. Incluye las interfaces de usuario Sirve para validar los requisitos: analista y

usuarios llegan a un acuerdo sobre lafuncionalidad y vocabulario.

Prototipo desechable Fcil de construir con herramientas visuales.

67


68/84

RESUMEN de requisitos

68

Fase II


69/84

Requerimientos( ASI ) Objetivos de la Fase

Obtener una especificacin detallada

del Sistema de Informacin quesatisfaga las necesidades deInformacin de los usuarios y sirva debase para el diseo posterior del

sistema.

se

69

Fase II


70/84

Requerimientos

Actividades ASI 1. Requerimientos del Sistema de

Informacin ASI 2. Anlisis de los Casos de Uso

ASI 3. Anlisis de Clases

ASI 4. Anlisis de Paquetes

ASI 5. Especificacin de Interfaces con otrossistemas

Fase II

70

Fase II \ Actividad 1


71/84

Objetivo Determinar el alcance del sistema y la

especificacin de las interfaces entre elsistema y el usuario.

Participantes

Analista de sistemas (responsable de toda laactividad) Equipo de Usuarios


ASI 1. Requerimientos del Sistema

de Informacin

71



72/84

ASI 1. Requerimientos del

Sistema de informacionTcnicas

Diagrama de Contexto del Sistema

Diagrama de Casos de Uso del Sistema Diagrama de Paquetes (Subsistemas.

Objetos)

Prctica Sesiones de Trabajo

Catalogacin

Prototipeo

72



73/84

ASI 1. Modelado de los

Requerimientos del SistemaTareas

ASI1.1 Determinacin del Alcance del Sistema

ASI1.2 Obtencin de Requerimientos ASI1.3 Obtencin del Modelo de Casos de Uso del

Sistema

ASI1.4 Especificacin de formatos individuales de laInterface de pantalla

ASI1.5 Identificacin de Perfiles y Dialogos ASI1.6 Especificacin de Formatos de Impresin

73

Fase II \ Actividad 1 \ Tarea 1


74/84

ASI 1.1 Determinacin del

Alcance del Sistema Se delimita el dominio del Sistema de

Informacin, en base a los Procesos de

Negocio Identificados. Se identifican las entidades externas al

sistema que aportan o reciben

informacin

74

Fase II \ Actividad 1 \Tarea 1


75/84

ASI 1.1 Determinacin del

Alcance del Sistema Se puede adicionar un diagrama de

contexto, a fin de graficar el alcance delsistema.

75



76/84

ASI 1.2 Obtencin de Requerimientos

RequerimientosFuncionales

Son losrelacionadoscon los serviciosespecificos delsistema a

implementar.


Nmero Requerimiento Descripcin PrioridadRF01 Registro de pagos Debe permitir el registro de pago de

manera eficiente

3

RF02 Registro de pacientes Debe permitir registro de los datos

del cliente y antecedentes clnicos.

4

RF03 Mantenimiento de

usuarios

Los nuevos usuarios o cambios en

los usuarios antiguos debe ser

administrado por el supervisor

2

RF04 Registrar resultados de

examen clnico

Debe permitir realizar el registro de

los resultados del examen clnico

5

RF05 Gestin de HistoriasClnicas

Se debe permitir la apertura,actualizacin o baja de las historias

clnicas.

5

RF06 Realizar Presupuesto Debe permitir la realizacin de

presupuesto de acuerdo al plan de

tratamiento y al paciente.

5

RF07 Diseo del plan de

tratamiento

Debe permitir disear el plan de

tratamiento de acuerdo a los

resultados del examen clnico dentaly al criterio del odontlogo.

5

RF08 MantenimientoGenerales

Debe permitir el mantenimiento detratamientos, pacientes

2

RF09 Programacin de citas El sistema debe permitir una

administracin adecuada dehorarios de atencin asignando un

espacio para la atencin del cliente.

4

RF10 Manejo de descuentos Debe permitir la realizacin dedescuentos por parte del odontlogo

de acuerdo a los pacientes.

3

RF11 Registrar resultados deintervencin

El sistema debe permitir registrarlos resultados despus de cada

intervencin as como las

observaciones.

5

RF12 Manejo de

Odontogramas

Debe permitir a los odontlogos el

manejo de odontogramas

permitindole modificar, guardar los

datos necesarios como los estados

de las piezas dentales.

5

RF13 Control de Ingresos El sistema debe permitir el calculo

de los ingresos percibidos durante el

mes

3

RF14 Registro de Gastos El sistema debe permitir el registrode todos los gastos realizados

3

76



77/84

ASI 1.2 Obtencin de Requerimientos

Requerimientos NoFuncionales Son los

relacionados con lascaractersiticasespeciales delsistema aimplementar, talescomo rendimiento,

seguridad,escalabilidad, etc

se \ c v d d \ e

Nmero Requerimiento Descripcin PrioridadRNF01 Avisar de error en la

Base de DatosCualquier error en la ubicacin de labase de datos principal o secundariadebe ser sealada durante elacceso al sistema

4

RNF02 Copia de Seguridad delsistema

El sistema debe permitir grabarsemanalmente una copia deseguridad de la base de datos ascomo su recuperacin.

3

RNF03 Reparar base de Datos Debe permitir compactar elcontenido de la base de datos

desechando los registros eliminadosy reconstruyendo los ndices.

3

RNF04 Visualizacin deOdontograma

El sistema debe mostrar unapantalla amigable donde seencuentre el odontograma.

5

RNF05 Facilidad en el ingresode informacin alodontograma

Debe permitir el manejo desmbolos estndares as como eluso fcil del Mouse para laasignacin de estos.

4

RNF06 Acceso a la informacin Solo las personas autorizadasdeben tener acceso a la

informacin, por tanto todas laspersonas que requieren informacindel sistema debern validarse.

3

RNF07 Disponibilidad deinformacin

Durante los horarios fuera de oficinasolo se podr tener acceso a lainformacin solo para su lectura.

3

RNF08 Tiempo de respuesta El sistema debe responder a lapeticin del usuario en un tiempo nomayor a 5 segundos.

4

RNF09 Disponibilidad deinformacin de paciente

La informacin de un paciente debeestar disponible para los diferentesmdulos que se utilizan durante su

atencin

5

77



78/84

ASI 1.3 Obtencin del Modelo de

Casos de Uso del Sistema. Se elabora el

Diagrama yladescripcinde los CU delSistema.

78



79/84

Relacin entre CU Negocio y CU

Sistema

SistemaSistema

NegocioNegocio

79



80/84

CU del Sistema - Descripcin

Flujo de Eventos

Caso de Uso:Apertura de historia clnica.Actores Principales: AsistentePersonal involucrado e intereses:o Asistente: Quiere guardar informacin personal del paciente, as como antecedentes

clnicos.

o Paciente: Requiere un servicio que es suministrado por el odontlogo. Desea que sus

datos queden registrados correctamente para su debido control.o Odontlogo: Requiere que la informacin del paciente sea precisa para que pueda

realizar las intervenciones adecua damente.

Precondiciones: El paciente solicita un servicio clnico dental, autentificacin del asistente.

Postcondiciones: La informacin quede registrada correctamente en una nueva historiaclnica.

Escenario principal de xito -Flujo Bsico:

1. El Asistente solicita apertura de historia clnica

2. El sistema apertura una historia clnica, muestra pantalla de historia y pantalla de

paciente.

3. El asistente ingresa datos del paciente.

4. El sistema registra los datos del paciente.5. El asistente ingresa datos de l a historia.

6. El sistema registra los datos de historia

Extensiones:

a.- En cualquier momento el sistema falla:

Para dar soporte a la recuperacin y registro correcto, asegura que todos los estados y

eventos significativos de una transaccin puedan recuperarse desde cualquier paso del

escenario.1. El asistente reinicia el sistema. Inicia la sesin y solicita la recuperacin al estado

anterior.

2. El sistema reconstruye el estado anterior

2. a.- El sistema detecta anomalas intentando la recuperacin.1. El sistema informa del error al asistente, registra el error, y pasa a un estado

limpio.

2. El asistente comienza una nueva apertura de historia clnica.1-3.a.-El paciente le pide al asistente que cancele la apertura de historia clnica.

1.- El asistente cancela la apertura de historia clnica.

4. a.- El sistema encuentra algn fallo para comunicarse con la base de datos.

1.-El sistema reinicia el servicio y continua1. a.- El sistema detecta que el servicio no se reinicia.

1.- El sistema seala el error.


6. a.- El sistema encuentra algn fallo para comunicarse con la base de datos.1.-El sistema reinicia el servicio y continua

1. a.- El sistema detecta que el servicio no se reinicia.

1.- El sistema seala el error.


REQUERIMIENTO ASOCIADORF02 Registro de pacientesRF05 Gestin de historias clnicas.

80



81/84

ASI 1.4 Especificacin de la

Interface de Usuario Se realiza un

prototipo delas pantallasdel sistema.

81



82/84

ASI 1.5 Identificacin de Perfiles

y Dilogos Se identifican los perfiles para cada rol establecido. Ejemplos

1. r l rfil Asistente2. i l ti

r r ci n e cit s, ertur ehist ri s clnic s, r egistr e gos, registroe inter enci n,

3. i Lectur , Modific ci n, eli inaci ne Inserci n

82



83/84

ASI 1.6 Especificacin de

Formatos de Impresin Se especifica los formatos y caracteristiacs de las salidas o

entradas impresas del sistema.

83


84/84

FIN Sesin 11

Analisis y Diseo de Sistemas

UNIVERSIDAD NACIONAL DE INGENIERIAFacultad de Ingeniera Industrial y de SistemasIng. Jess Walter Antaurco TrujilloW t @ h

Documents

ClaseAyD_11.pptx