TRABAJO PRACTICO

Nombre: Franco Montes Blacutt

Docente: Ernesto Soto Roca
Materia: ANALISIS DE SISTEMA I
Horario: 19:00 -21:45 Hrs





TRABAJO PRACTICO #1

SESIONES JAD
Las sesiones JAD y JRP son reuniones en las que se potencia el trabajo en equipo entre
el cliente o usuario y el proveedor, con una participacin ms activa del cliente en los
diferentes procesos del ciclo de vida.
Esto permite identificar las necesidades planteadas, proponer soluciones, negociar
enfoques diferentes y especificar el conjunto preliminar de requisitos que debe cumplir la
solucin para llegar al objetivo que se propone.

Caractersticas de una sesin de trabajo tipo JAD:
Se establece un equipo de trabajo cuyos componentes y responsabilidades estn perfectamente
identificados y su fin es conseguir el consenso entre las necesidades de los usuarios y los servicios
del sistema en produccin.
Se llevan a cabo pocas reuniones, de larga duracin y muy bien preparadas.
Durante la propia sesin se elaboran los modelos empleando diagramas fciles de entender y
mantener, con herramientas
CASE.
Al finalizar la sesin se obtienen un conjunto de modelos que debern ser aprobados por los
participantes.
Perfiles:
Moderador con amplios conocimientos de la metodologa de trabajo, dinmica de grupos,
psicologa del comportamiento, as como de los procesos de la organizacin objeto del estudio.
Promotor, persona que ha impulsado el desarrollo.
Jefe de proyecto, responsable de la implantacin del proyecto.
Especialista en modelizacin, responsable de la elaboracin de los modelos en el transcurso de
la sesin.
Desarrolladores, aseguran que los modelos son correctos y responden a los requisitos
especificados.
Usuarios, responsables de definir los requisitos del sistema y validarlos
Actividades:
Inicio: se define el mbito y la estructura del proyecto, los productos a
obtener, se prepara el material necesario para la sesin, se determina
el lugar donde se van a llevar a cabo, se seleccionan los participantes y
se sugiere una agenda de trabajo.
Desarrollo: se identifican las salidas del proyecto y se debe conseguir
el consenso entre los participantes de modo que se materialice en los
modelos.
Finalizacin: se valida la informacin de la sesin y se generan los
productos de la metodologa de trabajo propuesta. Si fuera necesario
se integran los productos de salida. En las sesiones de trabajo tipo JAD
se distinguen
Dos tipos de productos:
De preparacin donde se incluye, entre otros, la historia y contexto del
proyecto, los objetivos y lmites, las actividades del entorno del negocio
que pueden afectar al xito del proyecto y los beneficios.
De resultado de las sesiones de trabajo, que se establecen con
anterioridad al inicio de las reuniones.















Plantilla de Documento JAD
INTRODUCCION
ste es un documento de trabajo para el proyecto... e incluye las especificaciones
propuestas como punto de partida en la sesin JAD.
AGENDA DE LA SESIN
1. Visin de conjunto
2. Supuestos
3. Flujo de trabajo
4. Datos elementales
5. Pantallas
6. Informes
7. Cuestiones abiertas
8. Lista de distribucin para la documentacin final
SUPUESTOS
El sistema debe incluir
CUESTIONES ABIERTAS
Cmo deben ser manejados...?
Se puede incluir un ndice. Y al final de cada seccin se pueden dar a los participantes notas que
digan en qu parte del documento de trabajo se han de fijar ms.










Estandar IEEE 830

El estndar 830-1998 fue generado por un equipo de trabajo del IEEE, su finalidad es la integracin
de los requerimientos del sistema desde la perspectiva del usuario, cliente y desarrollador.
la 830 se encarga de poner las pautas para identificar y esquemagtizar las requierimientos de
software. como parte integral del disarrollo de software, sino tambien como base fundamental de
este, todo esto con el fin de no caer en cambios, errores o situaciones que pongan en peligro la
creacion de una solucion, producto o software; incurriendo en gastos o cambios producto de una
mal analisis de requerimientos
objetivos:
Ya conociendo lo que es un SRS se debe establecer que funcin ubicada en el contexto de
desarrollo de software por esto se plantea lo siguiente:
- Un cliente describa claramente lo que quiere
- Un proveedor entienda claramente lo que el cliente quiere
- Se establezcan bases para un contrato de desarrollo (o de compra-venta)
- Se reduzca el esfuerzo de anlisis, diseo, y programacin (evitando re-trabajos)
Actores
De los estndares este es uno de los que mayor importancia lleva ya que este es el que define que
har la herramienta de software o solucin planteada.
- Un cliente/usuario que vaya a definir requerimientos (caractersticas) de un software que
necesite
- Un desarrollador (interno/externo) que haga software a la medida mediante proyecto
- Un desarrollador que haga software de paquete que se venda masivamente

PLANTILLA DE IEEE 830
Esquema de la ERS definida en el IEEE 830-1998
La siguiente figura muestra la estructura de la ERS propuesta por el IEEE en su estndar
830 [IEEE, 1998] [upm, 2000].
Figura 1. Estructura de una ERS
A continuacin se describir brevemente cada uno de los apartados que se
definen en el estndar estudiado.
1 Introduccin
En esta seccin se proporcionar una introduccin a todo el documento de
Especificacin de Requisitos Software. Consta de varias subsecciones, las cuales son
propsito, mbito del sistema, definiciones, referencias y visin general del documento.
1.1 Propsito
Se definir el propsito del documento ERS y se especificar a quin va dirigido
el documento.
1.2 mbito del Sistema
En esta subseccin se pondr nombre al futuro sistema, se explicar lo que el
sistema har y lo que no har, se describirn los beneficios, objetivos y metas que se
espera alcanzar con el futuro sistema y se mantendrn referencias a los documentos de
nivel superior que puedan existir.
1 Introduccin
1.1 Propsito
1.2 mbito del Sistema
1.3 Definiciones, Acrnimos y Abreviaturas
1.4 Referencias
1.5 Visin general del documento
2 Descripcin General
2.1 Perspectiva del Producto
2.2 Funciones del Producto
2.3 Caractersticas de los usuarios
2.4 Restricciones
2.5 Suposiciones y Dependencias
2.6 Requisitos Futuros
3 Requisitos Especficos
3.1 Interfaces Externas
3.2 Funciones
3.3 Requisitos de Rendimiento
3.4 Restricciones de Diseo
3.5 Atributos del Sistema
3.6 Otros Requisitos
4 Apndices
5 ndice
E78. Ingeniera del Software ERS segn el estndar IEEE 830 7
1.3 Definiciones, Acrnimos y Abreviaturas.
Se definirn aqu todos los trminos, acrnimos y abreviaturas utilizadas en el
desarrollo de la ERS.
1.4 Referencias
Se presentar una lista completa de todos los documentos referenciados en la
ERS.
1.5 Visin General del Producto
Esta subseccin describir brevemente los contenidos y la organizacin del resto
de la ERS.
2 Descripcin General
En esta seccin se describen todos aquellos factores que afectan al producto y a
sus requisitos. En esta seccin no se describen los requisitos, sino su contexto. Los
detalles de los requisitos de describen en la seccin 3, detallndolos y haciendo ms
fcil su comprensin.
Normalmente podemos encontrar las siguientes subsecciones: Perspectiva del
producto, funciones del producto, caractersticas de los usuarios, restricciones,
suposiciones y futuros requisitos.
2.1 Perspectiva del Producto
Esta subseccin debe relacionar el futuro sistema con otros productos. As pues,
podramos dividir sta en pequeas subsecciones indicando cada uno de los puntos a
tener en cuenta:
2.1.1. Indicar si es un producto independiente o parte de un sistema mayor
2.1.2. Interfaces de sistema
2.1.3. Interfaces de usuario
2.1.3.1. Caractersticas lgicas del interfaz
2.1.3.2. Cuestiones de optimizacin del interfaz de usuario
2.1.4. Interfaces hardware
2.1.5. Interfaces software
2.1.5.1. Descripcin del producto software utilizado
2.1.5.2. Propsito del interfaz
2.1.5.3. Definicin del interfaz: contenido y formato
2.1.6. Interfaces de comunicaciones
2.1.7. Limitaciones de memoria
2.1.8. Operaciones
2.1.8.1. Modos de operacin de los distintos grupos de usuarios
2.1.8.2. Periodos de operaciones interactivas y automticas
2.1.8.3. Funciones respaldo del procesamiento de datos
2.1.8.4. Operaciones de backup y recuperacin
2.1.9. Requerimientos para adaptarse a la ubicacin
2.1.9.1. Indicar cualquier dato o secuencia de inicializacin especfico de cualquier
lugar, modo de operacin.
2.1.9.2. Caractersticas que deben ser modificadas para una instalacin en
particular.
E78. Ingeniera del Software ERS segn el estndar IEEE 830 8
2.2 Funciones del Producto
Esta subseccin debe proporcionar un resumen de las funciones principales que el
software debe llevar a cabo. Las funciones deben estar organizadas de manera que el
cliente o cualquier otra persona lo entienda perfectamente. Para ello se pueden utilizar
mtodos textuales o grficos, siempre que dichos grficos reflejen las relaciones entre
funciones y no el diseo del sistema.
En la metodologa estructurada se podran utilizar los DFDs y en una metodologa
orientada a objetos, el funcionamiento y las relaciones del futuro sistema se modelaran
a travs de los Casos de Uso. En ellos se representa lo que el usuario ve del sistema, as
pues facilitar en gran medida su comprensin, siempre y cuando en los diagramas se
eviten las ambigedades.
2.3 Caractersticas de los usuarios
Se indica aqu el tipo de usuario al que se dirige la aplicacin, as como su
experiencia tcnica, nivel de conocimientos, etc.
2.4 Restricciones
Se debe indicar aqu cualquier tipo de limitacin como pueden ser polticas de la
empresa, limitaciones hardware, seguridad, protocolos de comunicacin, interfaces con
otras aplicaciones, estndares de la empresa en cuanto a interfaces, etc. Sern las
limitaciones que se imponen sobre los desarrolladores del producto.
2.5 Suposiciones y Dependencias
En este apartado aparecer cualquier factor, que si cambia puede afectar a los
requerimientos. No son restricciones de diseo, por ejemplo, asumir que un
determinado sistema operativo estar disponible, presuponer una cierta organizacin de
las unidades de la empresa. Si cambian ciertos detalles puede ser necesario revisar los
requisitos.
2.6 Requisitos Futuros
Se indican aqu posibles mejoras del sistema en el futuro. Estas mejoras deben
estudiarse y analizarse una vez concluido y puesto en marcha el sistema. Son
modificaciones a realizar en un futuro incierto.
3 Requisitos Especficos
Esta seccin de la especificacin de requisitos software contiene todos los
requerimientos hasta un nivel de detalle suficiente para permitir a los diseadores
disear un sistema que satisfaga dichos requisitos, y que permita disear las pruebas que
ratifiquen que el sistema cumple con las necesidades requeridas.
Los requisitos que se aqu se indiquen deben describir comportamientos externos
del sistema, observables por el usuario as como por parte de los operadores y otros
sistemas.
Puesto que deben indicarse todos los requisitos, esta seccin es la ms larga de la
ERS y debe cumplir los principios descritos en los primeros apartados de este informe.
Estos principios son la correccin, no ambigedad, completitud, consistencia,
clasificacin, verificabilidad, modificabilidad, explorabilidad y facilidad de
mantenimiento.
E78. Ingeniera del Software ERS segn el estndar IEEE 830 9
Asimismo, ste documento debe ser perfectamente legible por el cliente y por
personas de muy distinta formacin. Otra de las cuestiones a tener en cuenta en esta
seccin es la identificacin de cada uno de los requisitos mediante algn cdigo o
sistema de numeracin.
3.1 Interfaces Externas
En esta subseccin se definirn los requisitos que afecten a la interfaz de usuario
e interfaz con otros sistemas (hardware y software), as como a interfaces de
comunicaciones.
3.2 Funciones
En este subseccin de deben especificar todas aquellas acciones o funciones que
deber llevar a cabo el sistema a desarrollar. Las acciones que se indican como el
sistema deber ... son las que deben incluirse en este apartado.
La estructuracin de las funciones a desarrollar por el nuevo sistema no est del
todo claro. Se debe tener en cuenta que en el estndar de IEEE 830 de 1983 se
estableca que las funciones de deberan expresar como una jerarqua funcional (vase
anexo II), puesto que es la que mejor se adaptaba a los DFDs que propona el anlisis
estructurado. Con la evolucin de la programacin y los nuevos mtodos de anlisis se
puede observar como esta estructura no se adapta, por tanto es necesaria la modificacin
de los estndares.
El estndar IEEE 830, en sus ltimas versiones, permite la organizacin de esta
subseccin de mltiples formas y simplemente sugiere alguna manera para hacerlo,
dejando la oportunidad de utilizar cualquier otra justificando suficientemente la
utilizacin de sta.
Alguna de las formas sugeridas por el estndar son:
Por tipo de usuario: Distintos usuarios poseen distintos requisitos. Para
cada clase de usuario que exista en la organizacin, se especifican los
requisitos funcionales que le afecten o tengan mayor relacin con sus
tareas.
Por objetos: Los objetos son entidades del mundo real que son reflejadas
en el sistema. Por tanto, para cada objeto se detallan sus atributos y sus
funciones. Los objetos se pueden agrupar en clases. A pesar de realizar el
anlisis con objetos no obliga a que el diseo del sistema siga el
paradigma Orientado a Objetos, aunque lo facilita en gran medida.
Por objetivos: un objetivo es un servicio que se desea que ofrezca el
sistema y que requiere una determinada entrada para obtener su resultado.
Para cada objetivo o subobjetivo requerido al sistema, se detallarn las
funciones que permitan llevarlo a cabo.
Por jerarqua funcional: La funcionalidad del sistema se especifica como
una jerarqua de funciones que comparten entradas, salidas o datos del
propio sistema. Para cada funcin y subfuncin del sistema se detallar la
entrada, el proceso en el que interviene y la salida. Normalmente este tipo
de anlisis implica que el diseo siga el paradigma de diseo estructurado.
Por lo general ste sistema se utiliza cuando ninguno de los anteriores se
puede aplicar.
E78. Ingeniera del Software ERS segn el estndar IEEE 830 10
Como se puede apreciar, el estndar propone una serie de plantillas segn el tipo
de sistema con el que nos enfrentemos. Pero en muchas ocasiones la eleccin se realiza
por eliminacin, o lo que es lo mismo, se escoge aquel que mejor se adapta a lo que se
busca.
3.3 Requisitos de Rendimiento
En esta subseccin se incluyen los requisitos relacionados con la carga que se
espera que tenga que soportar el sistema (nmero de usuarios simultneos, nmero de
terminales ...). Asimismo, se pueden incluir los requisitos que afecten a la informacin
que se vaya a guardar en la base de datos (cantidad de registros en una base de datos,
frecuencia de uso...)
3.4 Restricciones de Diseo
Se incluyen aqu todas las restricciones que afecten al diseo de la aplicacin,
como pueden ser estndares internos de la organizacin, limitaciones hardware, etc.
3.5 Atributos del Sistema
Se detallarn atributos como la fiabilidad, mantenibilidad, seguridad, mecanismos
de acceso restringido (password), usuarios autorizados a realizar ciertas tareas crticas ...
3.6 Otros requisitos
Aquellos requerimientos que no se hayan podido incluir en ninguna de las
secciones anteriormente especificadas.
4 Apndices
Se incluir aqu cualquier tipo de informacin relacionada con la ERS, pero que
no forme parte de la misma. Por ejemplo, se incluiran los resultados del anlisis de
costes, restricciones especiales acerca del lenguaje de programacin...
5 ndice
Se proporciona un ndice para poder tener un acceso rpido a la documentacin
presentada en la ERS.



ENTREVISTA
Los mtodos clsicos se basan en entrevistas bilaterales (el analista y cada una de las partes)
con lo que dejan para el analista toda la labor de organizacin y obtencin de un
consenso, recientemente se tiende a prcticas ms relacionadas con el
brainstorming en el que cada parte expone sus ideas y propuestas y se produce
un debate de forma que las posiciones vayan acercndose sucesivamente hasta
que se llegue a un consenso [Raghavan].
Antes de mantener las reuniones con los clientes y usuarios e identificar
los requerimientos es fundamental conocer el dominio del problema. Enfrentarse
a un desarrollo sin conocer las caractersticas principales ni el vocabulario propio
de su dominio suele provocar que el producto final no sea el esperado por
clientes ni usuarios. Por otro lado, mantener reuniones con clientes y usuarios
sin conocer las caractersticas de su actividad har que probablemente no se
entiendan sus necesidades y que su confianza inicial hacia el desarrollo se vea
deteriorada enormemente.
_
Para conocer el dominio del problema se puede obtener informacin de
fuentes externas al negocio del cliente: folletos, informes sobre el sector,
publicaciones, consultas con expertos, etc. En el caso de que se trate de un
dominio muy especfico puede ser necesario recurrir a fuentes internas al propio
negocio del cliente, en cuyo caso pueden utilizarse las tcnicas de elicitacin de
requerimientos como el estudio de documentacin, observacin in situ,
cuestionarios, etc.




MOCKUP

Un mockup es un prototipo si proporciona al menos una parte de la funcionalidad de un sistema y
permite pruebas del diseo.
1
Los mockups son utilizados por los diseadores principalmente para
la adquisicin comentarios de los usuarios. Los mock-ups abordan la idea capturada en la
ingeniera popular
En ingeniera de software: lo ms comn es crear una interface que muestre al usuario
final cmo lucir el programa sin tener construido el software o la funcionalidad
determinada.
Mockup: prototipo
La razn principal para crear prototipos es para poder hacer pruebas en una gran parte del
sistema, en una unidad, sin el uso de mdulos dependientes.
deriva resultados de la prueba para implementar productos y usabilidad en toda la
herramienta
Wireframe (Diseo web) Una ilustracin visual que muestra detalles.
Un wireframe para un sitio web, tambin conocido como un esquema de pgina o plano de
pantalla, es una gua visual que representa el esqueleto o estructura visual de un sitio web.
Los wireframes se enfocan en: Los tipos de informacin que ser mostrada. La
cantidad de las funciones disponibles. Las prioridades relativas de la informacin y las
funciones. Las reglas para mostrar ciertos tipos de informacin. El efecto de los
distintos escenarios en la pantalla.
Landing page: el primer contacto con su cliente/usuario y tal vez, su nica oportunidad.
Debe generar un impulso
Formato de pgina de venta
Para tener en cuenta: usabilidad + look and feel.