Procesos de Resolucin de

Problemas
Para resolver un problema, siempre en el alto nivel de detalle
se sigue el mismo proceso de
resolucin:
1. Identificar el problema
2. Definir y representar el problema
3. Explorar las posibles estrategias
4. Aplicar y mejorar las estrategias
5. Mirar atrs y evaluar los efectos de la actividad realizada (se
ha resuelto el problema?)
Este proceso es semejante al anterior pero ms simple:
1. Decidir qu hacer (cul es el problema)
2. Decidir cmo hacerlo
3. Hacerlo
4. Probar el resultado
5. Usar el resultado
El proceso mnimo necesario para resolver el problema de
la construccin de un sistema de
software es:
1. Obtencin de Requisitos de Software
2. Disear
3. Implementar
4. Realizar pruebas
5. Instalar
6. Mantener y Ampliar}
Primitivas del Anlisis
Tcnicas de Manejo y Reduccin de la Complejidad
Abstraccin
Sustituir una cosa o conjunto de cosas, por otra parte que
sumariza o resume a las cosas
sustituidas
Particin
Tcnica de Descomposicin. Dividir un problema complejo en
varios sub-problemas ya que de esta
forma la complejidad inherente al problema inicial se reparte
entre los distintos sub-problemas
Proyeccin
Ver un problema desde distintos puntos de vista
Caractersticas de los Distintos Dominios
Inconsistencia
La informacin que se obtiene al sumergirse en el dominio del
usuario no es coherente. Se deben
consultar diversas fuentes
Incompletitud
La informacin relevante para el ingeniero de requerimientos o
analista no acostumbra a estar
centralizada, sino dispersa en distintas fuentes
Ambigedad.
La informacin no es clara, pudiendo entenderse en varios
sentidos sin poder, a priori, adjudicar
unos de ellos unvocamente
Conceptos Generales de
Tcnicas de Anlisis
El anlisis trata de resolver el Qu?, mientras que
el diseo el Cmo?

Que es?: la palabra escrita es un vehculo
maravilloso para la comunicacin, pero no es,
necesariamente, la mejor forma de representar los
requisitos para el software. El modelado del
anlisis utiliza una combinacin de formatos en texto y
diagramas para representar los
requisitos de los datos, las funciones y el
comportamiento de una manera que es relativamente
fcil de entender y, an ms importante, conduce a una
revisin para lograr la correccin, la
integridad y la consistencia. Refinar los requisitos.
Quin lo hace?: un ingeniero de software (Ingeniero
de Requerimientos, Analista) construye
el modelo empleando requisitos obtenidos del cliente.
Por qu es importante?: para validar los requisitos
del software es necesario examinarlos
desde algunos puntos de vista diferentes. El modelado
del anlisis representa los requisitos en
mltiples "dimensiones", con lo que se incrementa la
probabilidad de encontrar errores, de que
surjan inconsistencias y de que se descubran omisiones.
Ingeniera de ReCules son los pasos?: los requisitos de
informacin, funcionales y de comportamiento se
modelan mediante varios tipos de diagramas. El
modelado basado en escenarios representa el
sistema desde el punto de vista del usuario. El
modelado orientado al flujo indica cmo se
transforman los objetos de datos al realizarse las
funciones del procesamiento. El modelado
basado en clases define objetos, atributos y relaciones.
El modelado del comportamiento
presenta los estados del sistema y sus clases, as como
el impacto de los eventos sobre sus
estados. Una vez que se han creado los modelos
preliminares, stos se refinan y analizan para
evaluar su calidad, integridad y consistencia. Despus,
el modelo de anlisis final lo validan los
interesados.
Cul es el producto obtenido?: para el modelo de
anlisis es posible elegir una amplia
variedad de tipos de diagramas. Cada una de estas
representaciones ofrece una visin de uno
o ms de los elementos del modelo.
Cmo puedo estar seguro de que lo he hecho
correctamente?: los productos de trabajo
del modelado del anlisis deben revisarse en lo relativo
a su correccin, integridad y
consistencia. stos deben reflejar las necesidades de
todos los interesados (stakeholders) y
establecer una base desde la cual pueda conducirse el
diseo.
Varias reglas prcticas que deben seguirse para
crear el modelo de anlisis
El modelo debe centrarse en los requisitos visibles
dentro del problema o dominio de
negocio. El grado de abstraccin debe ser alto de forma
relativa. "No se debe perder
tiempo en detalles" que tratan de explicar cmo
funcionar el sistema.
Cada elemento del modelo de anlisis debe agregarse
a un acuerdo general de los
requisitos de software y proporcionar una visin interna
del dominio de informacin,
funcin y comportamiento del sistema.
Debe retrasarse la consideracin de la infraestructura
y otros modelos no funcionales
hasta el diseo. Por ejemplo, es posible que se requiera
una base de datos, pero las
clases necesarias para implementarla, las funciones que
se requieren para acceder a
ella y el comportamiento que se exhibir cuando se
utilice debe considerarse slo
despus de que se haya completado el anlisis de
dominio del problema.
Varias reglas prcticas que deben seguirse para
crear el modelo de anlisis
Se debe minimizar el acoplamiento de todo el sistema.
Es importante representar las
relaciones entre clases y funciones. Sin embargo, si el
nivel de "interconexin" es
extremadamente alto se deben hacer esfuerzos para
reducirlo.
Se debe tener la seguridad de que el modelo de
anlisis proporciona valor a todos
interesados. Cada circunscripcin tiene su propio uso
del modelo. Por los interesados
relacionados con los negocios deben utilizar el modelo
para validar los requisitos; los
diseadores, como base para el diseo; la gente de
aseguramiento de la calidad, como
ayuda para planear pruebas de aceptacin.
El modelo debe mantenerse tan simple como sea
posible. No se deben agregar
diagramas adicionales cuando stos no ofrezcan
informacin nueva. No se deben
utilizar formas de notacin nuevas cuando basta con
una simple lista.
Qu es un Modelo?
Un modelo es una abstraccin del sistema,
especificando el sistema modelado desde
un cierto punto de vista y en un determinado nivel de
abstraccin. Un punto de vista es
por ejemplo una vista de especificacin o una vista de
diseo de sistema
Los modelos son abstracciones del sistema que
construyen los arquitectos y
desarrolladores. Por ejemplo los trabajadores que
modelan los requisitos funcionales,
piensan en el sistema con los stakeholders fuera de l y
con los casos de usos en su
interior, no se preocupan de cmo es el sistema por
dentro, solo de lo que puede hacer
para sus usuarios
Los trabajadores que construyen el diseo, piensan
en los elementos estructurales
como subsistemas y clases
Un modelo es una abstraccin semnticamente
cerrada del sistema, es decir es una
vista autocontenida en el sentido que un stakeholder de
un modelo no necesita para
interpretarlo mas informacin de otros modelos
Un modelo es una representacin que capta los
aspectos ms importantes de lo que
estamos modelando y simplifica u omiten el resto. Un
modelo de un sistema software
est construido en un lenguaje de modelado. Tiene
semntica y notacin. Incluye
grficos y texto
Modelo del Sistema
Qu utilidad brindan los Modelos?
Para pensar el diseo de un sistema
La simplicidad de crear y de modificar modelos
permite un pensamiento creativo e
innovacin a bajo precio
Para explorar econmicamente mltiples soluciones
Para trabajar con sistemas complejos
Los modelos son abstracciones de la realidad que nos
permiten describirla en trminos
comprensibles para todos los interesados
Facilitan la puesta en comn y la
comunicacinquerimientos 5