1. UNIVERSIDAD ESTATAL DE BOLIVAR.
ESCUELA DE: INFORMATICA EDUCATIVA.
DOCENTE:LIC MARCELO BAÑO.
TRABAJO DE: DESARROLLO DEL SOFTWARE II.
ESTUDIANTE: LORENA AGUIAR.
PATRICIA VERDEZOTO
2. TEMA: .
CONSTRUCCION DEL MODELO DE ANALISIS.
El objetivo del modelo es describir los dominios de
información el funcionamiento, u el comportamiento
para un sistema basado en computadoras.
El modelo de análisis es un representación de los
requisitos en un momento determinado.
ELEMENTOS DEL MODELO DE ANALISIS
Elementos basados en escenarios.- son los
primeros que se desarrollan durante la elaboración
del modelo.
3. Elementos basados en clases
Estos se clasifican en clases , una colección de clases con
atributos similares y comportamientos en común.
Elementos de comportamiento
Es un sistema basado en computadora el modelo de análisis
debe proporcionar elementos de modelado que muestren el
comportamiento.
Elementos basados al flujo
Cuando la información fluye a través de un sistema basado
en computadora esta se transforma en una variedad de
formas.
4. PATRONES DE ANALISIS
Los patrones de análisis aceleran el desarrollo de modelo
de análisis abstractos que capturan los requisitos
principales del problema.
Los patrones de análisis facilitan la transformación del
modelo de análisis en un modelo de diseño al seguir
patrones de diseño y soluciones confiables para problemas
comunes.
5. NEGOCIACIACION DE REQUISITOS
El cliente y el desarrollador entran en un proceso de
negociación en el cual se le ha de pedir al cliente un balance
de la funcionalidad el rendimiento y otras características del
sistema o producto frente al costo y el tiempo de colocación
en el mercado , el objetivo de esta negociación es desarrollar
un plan de proyecto que satisfaga las necesidades del cliente .
6. EL ARTE DE LA NEGOCIACION
El aprendizaje del arte de la negociación efectiva es una
actividad que sirve a través de la vida técnica y personal
Reconocer que no es una competencia.
Diseñar una estrategia, decidir que es lo que desearía
lograr.
Escuchar de manera activa.
Enfocarse en los intereses de la otra parte.
No dejar que se vuelva personal .
Ser creativo.
Estar listo para pactar .
7. FILOSOFIA Y OBJETIVOS GENERALES
EL modelo de análisis debe cumplir los tres objetivos
primarios
Describe lo que quiere el cliente .
Establecer una base para la creación de un diseño de
software.
definir un conjunto de requisitos que puedan validarse
una vez construido el software.
8. REGLAS PRACTICAS PARA EL MODELADO DE
ANALISIS
El modelo debe centrase en los requisitos visibles dentro.
del problema o dominio de negocio
Cada elemento del modelo de análisis debe agregarse a un
acuerdo general de los requisitos de software.
Debe retrasarse la consideración de la infra estructura y
otros modelos no funcionales hasta el diseño.
Se debe minimizar el acoplamiento de todo el sistema .
9. Se debe tener la seguridad de que el modelo de análisis
proporciona valor a todos los interesados .
El modelo debe mantenerse tan simple como sea posible .
El modelo de requisitos refleja de manera apropiada la
información la función y el comportamiento del sistema
que será construido.
El modelo de requisitos se a sometido a participar para
que expongan en forma progresiva información mas
detallada acerca del sistema
10. ANALISIS DE REQUISITOS
El análisis de requisitos genera la especificación de
características operacionales de software con otros elementos
del sistema y establece las restricciones que tiene el software.
Permite al ingeniero construir elementos que representen
escenarios del usuario actividades funcionales clases de
problemas y sus relaciones
ANALISIS DEL DOMINIO
Es encontrar o crear aquellas clases de análisis o funciones y
características comunes que se aplican ampliamente para que
puedan reutilizarse
11. VALIDACION DE LOS REQUISITOS
Cada requisito es consistente con el objetivo general del
sistema / producto.
Todos los requisitos han sido especificados con el grado de
atracción .
El requisito es necesario en realidad o presenta una
característica .
Cada requisito esta limitado y no es ambiguo.
Cada requisito tiene una atribución determinada para cada
requisito.
12. Algunos requisitos entran en conflicto con otros.
Cada requisito es alcanzable en el ambiente técnico que
recibirá al sistema o producto.
Cada requisito se puede probar una vez que este haya sido
implementado