Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Equipo_#5

No description
by

Juan Navarro

on 29 March 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Equipo_#5

El RAD (Documento de Análisis de Requerimientos) una vez publicado será considerado como una línea base y se pondrá bajo la administración de la configuración. Equipo 5 (cc) image by nuonsolarteam on Flickr Sergio Martinez Alzate
Stephany Angulo Salgado
Juan Navarro Sanchez Administración del Análisis En esta sección se tratan asuntos relacionados con la administración de las actividades de análisis en un proyecto de desarrollo de varios equipos.
El reto principal de la administración de los requerimientos en estos proyectos es mantener la consistencia mientras se usan tantos recursos. Al final el documento de análisis de requerimientos debe describir un solo sistema coherente que sea comprensible para una sola persona. Asignación de Responsabilidades El análisis requiere la participación de un amplio rango de individuos. El usuario de destino proporciona conocimiento sobre el dominio de aplicación. EI cliente proporciona los fondos para el proyecto y coordina el esfuerzo del lado del usuario. El analista obtiene conocimiento del dominio de aplicación y lo formaliza. Los desarrolladores proporcionan retroalimentación sobre factibilidad y costo. El gerente del proyecto coordina el esfuerzo del lado del desarrollo. Engrandes sistemas pueden estar involucrados muchos usuarios, analistas y desarrolladores, introduciendo retos adicionales para los requerimientos de integración y comunicación del proyecto. Estos retos pueden satisfacerse asignando papeles y alcances bien definidos a los individuos. Hay tres tipos principales de papeles: generación de información, integración y revisión. El usuario es el experto en el dominio de aplicación, quien genera información acerca del sistema actual, el ambiente del sistema futuro y las tareas que debe soportar. Cada usuario corresponde a uno o más actores y ayuda a identificar sus casos de uso asociados. El cliente, un papel de integración, define el alcance del sistema con base en los requerimientos del usuario. Diferentes usuarios pueden tener diferentes vistas del sistema, ya sea debido a que se beneficiarán de diferentes partes del sistema (por ejemplo, un despachador frente a un oficial de campo) o debido a que los usuarios tienen opiniones o expectativas diferentes acerca del sistema futuro. El cliente sirve como integrador de la información del dominio de aplicación y resuelve inconsistencias en las expectativas del usuario. El analista es el experto del dominio de desarrollo, quien modela el sistema actual y genera información acerca del sistema futuro. Al inicio cada analista es responsable de detallar uno o más casos de uso. Para un conjunto de casos de uso, el análisis identificara una cantidad de objetos, sus asociaciones y sus atributos. El editor de documentos es responsable de la integración de bajo nivel del documento. El editor de documentos es responsable del formato general del documento y de su índice. El tamaño del sistema determina la cantidad de usuarios y analistas diferentes que se necesitan para obtener y modelar los requerimientos. En todos los casos deberá haber un papel integrador del lado del cliente y otro del lado del desarrollo. Al final, sin importar qué tan grande sea el sistema, Ios requerimientos deberán ser comprensibles para un solo individuo que tenga conocimiento del dominio de aplicación. Ningún método de requerimientos o mecanismo de comunicación puede resolver los problemas relacionados con las políticas internas y la ocultación de información. Los objetivos en conflicto y la competencia siempre serán parte de los proyectos de desarrollo grandes. Sin embargo, unos cuantos lineamientos pueden ayudar a manejar la complejidad de vistas conflictivas del sistema: Lluvia de ideas. Poner a todos los interesados juntos en el mismo salón y hacer que generen con rapidez soluciones y definiciones puede eliminar muchas barreras en la comunicación. La realización de entrevistas como actividad recíproca (es decir, la revisión por parte del cliente y los desarrolladores, durante la misma sesión, de los productos a entregar) tiene un efecto similar. Aprobación del Cliente La aprobación del cliente representa la aceptación del modelo de análisis (como está documentada en el documento de análisis de requerimientos) por parte del cliente. El cliente y los desarrolladores convergen en una sola idea y se ponen de acuerdo acerca de las funciones y características que tendrá el sistema. Además se ponen de acuerdo en:
Una lista de prioridades
Un proceso de revisión
Una lista de criterios que se usarán para aceptar o rechazar el sistema
Una calendarización y un presupuesto Figura 5.23 Un ejemplo de un proceso de revisión (diagrama de actividades UML). El lenguaje natural es una herramienta imprecisa, y un modelo de objetos derivado literalmente del texto tiene el riesgo de ser impreciso.
Los desarrolladores nombran y describen en forma breve los objetos, sus atributos y sus responsabilidades conforme los identifican.la denominación única de los objetos promueve una terminología estándar.la descripción de los objetos permite que los desarrolladores aclaren los conceptos que usan y eviten errores.
5.1 Introducción: Una ilusión óptica
5.2 Un panorama del análisis
5.3 Conceptos de análisis
Análisis Resumen del análisis
La actividad de requerimientos es sumamente iterativa e incremental. Se bosqueja y proponen bloques de funcionalidad a los usuarios y clientes. El cliente añade requerimientos adicionales, critica la funcionalidad existente y modifica los requerimientos existentes. Los desarrolladores investigan los requerimientos no funcionales mediante la elaboración de prototipo y estudios de tecnología, y ponen a prueba cada requerimito propuesto. Conforme crese la descripción del sistema y los requerimientos se hacen más concretos, los desarrolladores necesitan extender y modificar el modelo de análisis de forma más ordenada para administrar la complejidad de la información.

El análisis
Da como resultado un modelo del sistema que pretende ser correcto, completo, consistente y verificable. Durante la obtención de requerimientos se examinan con mayor detalle las condiciones de frontera y los casos excepcionales, corrigen y aclaran la especificación del sistema. El cliente y el usuario están involucrados cundo se necesita cambiar la especificación del sistema y cuando se necesita recopilar información adicional. Análisis orientado a objetos Los desarrolladores construyen un modelo que describe al dominio de la aplicación, como sería el modelo de análisis de un reloj describe la manera en que el reloj representa al tiempo. Los desarrolladores usan el modelo de análisis, para preparar la arquitectura del sistema que se desarrolla durante el diseño de alto nivel. Análisis orientado a objetos 4 5 Los desarrolladores construyen un modelo que describe al dominio de la aplicación, como sería el modelo de análisis de un reloj describe la manera en que el reloj representa al tiempo. Los desarrolladores usan el modelo de análisis, para preparar la arquitectura del sistema que se desarrolla durante el diseño de alto nivel. Las actividades del análisis •Nos enfocamos en la identificación de objetos, su comportamiento, sus relaciones, su clasificación y su organización.
•Revisamos en forma breve las presentaciones y métodos del análisis que no esta orientado objetos y
•por último se describen los asuntos de administración relacionados con el análisis en el contexto de un proyecto de desarrollo de varios equipos.
Introducción: Una Ilusión Óptica En 1915, Rubin mostro una imagen similar a la figura que se muestra enseguida para ilustrar el concepto de imágenes multiestables. Si la imagen hubiera sido una especificación de sistema, ¿Cuáles modelos habría que construir? Las especificaciones, asi como las imágenes multiestables, contienen ambigüedades causadas por las imprecisiones al lenguaje natural y por las suposiciones de autores acerca de las especificaciones.
Por ejemplo una cantidad especificada sin unidades es ambigua o una hora sin zona horaria es ambigua.
Un panorama del análisis El análisis se enfoca en la producción de un modelo del sistema, llamado el modelo del análisis. El análisis se diferencia de la obtención de requerimientos en que los desarrolladores se enfocan en la estructura y la formalización de requerimientos obtenidos de los usuarios. El análisis ayuda a que los desarrolladores verifiquen la especificación del sistema producida durante la obtención de requerimientos, esto puede que no sea comprensible para el usuario y el cliente. Hay una tendencia de que los usuarios y desarrolladores pospongan las decisiones mas difíciles para el final del proyecto. Una de las razones pueden ser que tenga una falta de conocimiento del dominio, tecnológico o desacuerdos entre desarrolladores y usuarios. Objetos de entidad, frontera y control El modelo de objetos de análisis consiste en objetos de entidad, frontera y control.
Los objetos de entidad representan la información persistente rastreada por el sistema.
Los objetos de frontera representan la interacción entre los actores y el sistema.
Los objetos control representan las tareas realizadas por el usuario y soportadas por el sistema.
El análisis se enfoca en la producción de un modelo del sistema, llamado el modelo del análisis. El análisis se diferencia de la obtención de requerimientos en que los desarrolladores se enfocan en la estructura y la formalización de requerimientos obtenidos de los usuarios.
Full transcript